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

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


+
Bruce Mitchener 2010-04-07, 22:13
+
Bruce Mitchener 2010-04-08, 15:54
+
Bo Shi 2010-04-08, 21:49
+
Bruce Mitchener 2010-04-08, 22:19
+
Doug Cutting 2010-04-08, 22:43
+
Jeremy Custenborder 2010-04-09, 01:29
+
Bruce Mitchener 2010-04-09, 06:35
+
Scott Carey 2010-04-09, 16:00
+
Bruce Mitchener 2010-04-09, 16:16
+
Bo Shi 2010-04-09, 18:56
+
Scott Carey 2010-04-09, 20:54
+
Doug Cutting 2010-04-09, 21:29
+
Jeff Hodges 2010-04-10, 17:48
+
Jeff Hodges 2010-04-10, 17:53
+
Jeff Hodges 2010-04-10, 17:57
+
Bruce Mitchener 2010-04-10, 17:59
+
Jeff Hodges 2010-04-10, 18:08
+
Doug Cutting 2010-04-12, 20:46
+
Jeff Hodges 2010-04-12, 21:48
Copy link to this message
-
Re: Thoughts on an RPC protocol
Jeff Hodges 2010-04-12, 21:58
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!
--
Jeff

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