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 > >>> > >> > > >
