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
Er, note that I'm generally lightly positive on using it as a
influence on the protocol, even if portions of the philosophy I find
less than ideal. I mentioned the lack of community because a lack of
active  means whatever obstacles occur due to its fundamental nature
aren't well-known and well-defined. That's reasonable, if not ideal,
as we are already talking about building our own RPC!

On Mon, Apr 12, 2010 at 2:48 PM, Jeff Hodges <[EMAIL PROTECTED]> wrote:
> 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