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 >
