Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro, mail # dev - Thoughts on an RPC protocol


Copy link to this message
-
Re: Thoughts on an RPC protocol
Jeff Hodges 2010-04-12, 21:48
I hadn't thought of adding SASL to SPDY. I haven't dived into the
community, yet, to see if they've discussed it.

The philosophy behind BEEP seems pretty good, even if the crazy XML
style of the actual spec is not a good match (as put in an earlier
email). The lack of community is worrisome, of course, but having it
as an influence in our own design is probably worthwhile.

I do worry about the desire not to "name" things. URIs seem so
obviously a good in a system that they should be consistent for any
implementation of the protocol and instance of its use. However, I
recognize how much of a bite that is to chew if we don't take a
substantial portion of a spec into our own that already has that
defined. I'm not trying to push a REST dogma. Building a spec without
RESTful design is fine by me, as long as we recognize the tradeoffs.
--
Jeff

On Mon, Apr 12, 2010 at 1:46 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:
> Jeff Hodges 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
>
> I like that SPDY is more actively developed than BEEP.  It would be nice not
> to have to re-implement clients and servers from scratch, and to perhaps
> even use a pre-existing specfication.
>
> SPDY does fix one of the primary restrictions of HTTP in that it permits
> request multiplexing: responses need not arrive in order.
>
> However other concerns folks have had about HTTP are that:
>  a. text headers are big and slow to process
>  b. SSL/TLS is heavyweight and inflexible for authentication
>
> SPDY addresses the size of headers by compressing them, but that may hinder
> the speed of header processing.
>
> SPDY uses SSL/TLS, so would have the same issues there.  Perhaps they could
> be convinced to adopt SASL instead of TLS?
>
> Doug
>