Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
>>
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB