avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Hodges <jhod...@twitter.com>
Subject Re: Thoughts on an RPC protocol
Date Sat, 10 Apr 2010 17:57:41 GMT
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 <jhodges@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 <jhodges@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 <cutting@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

View raw message