Slashdot Mirror
Internet Explorer Implements HTTP/2 Support
jones_supa writes: As part of the Windows 10 Technical Preview, Internet Explorer will introduce HTTP/2 support, along with performance improvements to the Chakra JavaScript engine, and a top-level domains parsing algorithm based on publicsuffix.org. HTTP/2 is a new standard by the Internet Engineering Task Force. Unlike HTTP/1.1, the new standard communicates metadata in binary format to significantly reduce parsing complexity. While binary is usually more efficient than text, the real performance gains are expected to come from multiplexing. This is where multiple requests can be share the same TCP connection. With this, one stalled request won't block other requests from being honored. Header compression is another important performance concern for HTTP.
Re the resource usage issue - isnt IE's low(ish) resource usage only due to the fact that alot of what it needs to render a page is actually in the OS and thus loaded already before it needs it?
Slowly, web services are becoming a bad reimplementation* of CORBA. Once again, why did we jump on their band wagon?
As far as I understand it, SOAP is reimplementation of CORBA, whereas HTTP is a REST protocol.
Specifically, HTTP doesn't try to keep disparate systems synchronised; it is stateless and has no notion of "distributed objects". Every request contains all of the information necessary to generate a response, for example in HTTP Auth the credentials are included in every request.
Of course, people keep trying to re-introduce state back into the protocol, eg. for performance ("modified since") or to support stateful programs (cookies). These aren't necessary though; for example, we can replace cookies (protocol-level state) with serialised delimited continuations (content-level state) http://en.wikipedia.org/wiki/C...
Are you daft? Wait, nevermind. You are daft.
First of all, RESTful service structure is inadequate and inefficient. Most data isn't built to be dealt with at an entity level. That's the reason everyone got over ROR, and it's the reason RESTful services are useless. HTTP methods are to instruct the server how to handle the request, not the payload.
Second, a web service is a data service without presentation markup that is exposed via HTTP. That's literally what is required of a web (HTTP) service (data API). Aside from the lack of presentation markup, how the response is formatted is irrelevant. It could send back CSV for all anyone cares. JSON just so happens to be about eleventy-billion times more efficient than XML for most things. But for huge lists, CSV would be even more efficient than JSON. And for strictly-validated systems (read: interfaced with a fragile, ancient mainframe system that requires precise formatting of inputs because the CxO's want to keep COBOL around for cost reasons and "if-it-ain't-broke" doesn't equate to "if-it-ain't-shitty"), nothing beats the verifiability of XML and good old SOAP/WSDL-style web services.
If I were one to jump to conclusions (and, face it, I am, or I wouldn't be posting this), I'd say that you're one of those guys that works with Javascript all day and doesn't (yet) equate it to mental abuse.
This won't effect AJAX. HTTP is abstracted away from the javascript engine by the browser. I imagine there might be some additional HTTP header parameters to play with while making AJAX calls, but that's about it. All the benefits from HTTP/2 will happen behind scene as far as AJAX is concerned.