I may have misunderstood the direction this thread had taken. I'm still going through the spec. -- Jeff
On Sat, Apr 10, 2010 at 10:59 AM, Bruce Mitchener <bruce.mitche...@gmail.com> wrote: > What specific changes would you propose making to my proposal? > > - Bruce > > On Sat, Apr 10, 2010 at 11:57 AM, Jeff Hodges <jhod...@twitter.com> wrote: > >> Sorry for the spam. Python, java and apache httpd implementations >> listed at the project page: http://www.chromium.org/spdy >> >> On Sat, Apr 10, 2010 at 10:53 AM, Jeff Hodges <jhod...@twitter.com> wrote: >> > 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 >> >>> >> >> >> > >> >
