45 ms·

While your points are valid in order for webapps to continue their march in to desktop app territory they need to decrease latency. I think this is what spdy is

While your points are valid in order for webapps to continue their march in to desktop app territory they need to decrease latency. I think this is what spdy is there for. I'm sure a lot of fat will be added to apps but if my AJAX requests are snappier I am more then happy to support this.

jacquesm 17y ago
from: http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepa... "To target a 50% reduction in page load time. Our preliminary results have come close to this target (see below)." The bigger chunk of which seems to come from header compression. SPDY is targeted to be placed between HTTP and TCP. It 'only' requires changes to the client and the webservers. That makes me a little skeptical about the value of their tests, I can't imagine they got the top 500 websites to change their server architecture to allow this test to take place. They are very much focused on the latency issues but the only references they give are for things related to page load time, which are affected peripherally by latency, but latency is much more of an effect on single connections. And the only gain from that would be to compress the headers. If header compression is that much of a deal then I would suggest to add optional header compression to the http standard, not to place layers in between http and tcp. And that layer would have to add 0 overhead all by itself on single connections or the results would be negative instead of positive. You can't really support this unless the client supports it as well, think of it as a specialized gateway function inside the browser that knows how to tunnel HTTP over SPDY to hosts that support it, the key factor is interleaving frames of content from different sources. Essentially a packet multiplexer/demultiplexer if I read it all right, that will pack all the requests on the sending side and unpack them at the receiving end to go to their respective handlers. By the way, the 'server pushes resources before the client has asked for it' is what has been making my webcam software functional for the last 15 years or so. I clued in to that in '95 or so using the server-push technology and figured out that since I already knew that the next request would be for another frame of the same cam why not send it right now instead of waiting for the browser to ask for it...

jacquesm 17y ago

from: http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepa... "To target a 50% reduction in page load time. Our preliminary results have come close to this target (see below)." The bigger chunk of which seems to come from header compression. SPDY is targeted to be placed between HTTP and TCP. It 'only' requires changes to the client and the webservers. That makes me a little skeptical about the value of their tests, I can't imagine they got the top 500 websites to change their server architecture to allow this test to take place. They are very much focused on the latency issues but the only references they give are for things related to page load time, which are affected peripherally by latency, but latency is much more of an effect on single connections. And the only gain from that would be to compress the headers. If header compression is that much of a deal then I would suggest to add optional header compression to the http standard, not to place layers in between http and tcp. And that layer would have to add 0 overhead all by itself on single connections or the results would be negative instead of positive. You can't really support this unless the client supports it as well, think of it as a specialized gateway function inside the browser that knows how to tunnel HTTP over SPDY to hosts that support it, the key factor is interleaving frames of content from different sources. Essentially a packet multiplexer/demultiplexer if I read it all right, that will pack all the requests on the sending side and unpack them at the receiving end to go to their respective handlers. By the way, the 'server pushes resources before the client has asked for it' is what has been making my webcam software functional for the last 15 years or so. I clued in to that in '95 or so using the server-push technology and figured out that since I already knew that the next request would be for another frame of the same cam why not send it right now instead of waiting for the browser to ask for it...