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
Copy link to this message
-
Re: Thoughts on an RPC protocol
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
>
+
Jeff Hodges 2010-04-12, 21:58
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