Oh, and it's been partially implemented in Chromium, so there's a quasi-reference implementation. -- Jeff
On Sat, Apr 10, 2010 at 10:48 AM, Jeff Hodges <jhod...@twitter.com> wrote: > To throw another set of ideas into the hat, SPDY[1][2] would be good > to learn from. SPDY takes the basics of HTTP and makes them fast. > Benefits we would enjoy include: > > * Multiplexed streams > * Request prioritization > * HTTP header compression > * Server push > > Currently in draft form. > > [1] http://dev.chromium.org/spdy/spdy-whitepaper > [2] http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2 > -- > Jeff > On Fri, Apr 9, 2010 at 2:29 PM, Doug Cutting <cutt...@apache.org> wrote: >> Scott Carey wrote: >>> >>> I also have not wrapped my head around routing/proxy use cases. From >>> a somewhat ignorant perspective on them -- I'd rather have a solid >>> point-to-point protocol that just works, is simple, and can meet the >>> vast majority of use cases with high performance than one that >>> happens to be capable of sophisticated routing but has a lot of other >>> limitations or is a lot harder to implement and debug. >> >> FWIW, they're theoretical at this point. I was only stating that prefixing >> every request and response with handshakes makes stuff like proxies trivial, >> since the protocol becomes stateless. Once we start having sessions things >> get trickier. For example, many HTTP client libraries cache connections, >> so, if you're building on top of one of those, it's hard to know when a new >> connection is opened. >> >> One approach is to declare that the current framing and handshake rules only >> apply to HTTP, currently our only standard transport. Then we can define a >> new transport that's point-to-point, stateful, etc. which may handle framing >> and handshakes differently. Thus we can retain back-compatibility. Make >> sense? >> >> Doug >> >
