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-def
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 co
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 fo
I may have misunderstood the direction this thread had taken. I'm
still going through the spec.
--
Jeff
On Sat, Apr 10, 2010 at 10:59 AM, Bruce Mitchener
wrote:
> What specific changes would you propose making to my proposal?
>
> - Bruce
>
> On Sat, Apr 10, 2010 at 11:57 AM, Jeff Hodges wrote:
What specific changes would you propose making to my proposal?
- Bruce
On Sat, Apr 10, 2010 at 11:57 AM, Jeff Hodges wrote:
> Sorry for the spam. Python, java and apache httpd implementations
> listed at the project page: http://www.chromium.org/spdy
>
> On Sat, Apr 10, 2010 at 10:53 AM, Jeff
Sorry for the spam. Python, java and apache httpd implementations
listed at the project page: http://www.chromium.org/spdy
On Sat, Apr 10, 2010 at 10:53 AM, Jeff Hodges wrote:
> Oh, and it's been partially implemented in Chromium, so there's a
> quasi-reference implementation.
> --
> Jeff
>
> On
Oh, and it's been partially implemented in Chromium, so there's a
quasi-reference implementation.
--
Jeff
On Sat, Apr 10, 2010 at 10:48 AM, 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.
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.c
Scott Carey wrote:
I also have not wrapped my head around routing/proxy use cases. From
a somewhat ignorant perspective on them -- I'd rather have a solid
point-to-point protocol that just works, is simple, and can meet the
vast majority of use cases with high performance than one that
happens t
On Apr 9, 2010, at 11:56 AM, Bo Shi wrote:
> On Fri, Apr 9, 2010 at 2:35 AM, Bruce Mitchener
> wrote:
>> Doug,
>>
>> I'm happy to hear that you like this approach!
>>
>> Allocation of channels seems to be something specific to an application. In
>> my app, I'd have a channel for the streaming
On Fri, Apr 9, 2010 at 2:35 AM, Bruce Mitchener
wrote:
> Doug,
>
> I'm happy to hear that you like this approach!
>
> Allocation of channels seems to be something specific to an application. In
> my app, I'd have a channel for the streaming data that is constantly
> arriving and a channel for mak
On Fri, Apr 9, 2010 at 10:00 AM, Scott Carey wrote:
>
> On Apr 8, 2010, at 11:35 PM, Bruce Mitchener wrote:
>
> > Doug,
> >
> > I'm happy to hear that you like this approach!
> >
> > Allocation of channels seems to be something specific to an application.
> In
> > my app, I'd have a channel for t
On Apr 8, 2010, at 11:35 PM, Bruce Mitchener wrote:
> Doug,
>
> I'm happy to hear that you like this approach!
>
> Allocation of channels seems to be something specific to an application. In
> my app, I'd have a channel for the streaming data that is constantly
> arriving and a channel for mak
Doug,
I'm happy to hear that you like this approach!
Allocation of channels seems to be something specific to an application. In
my app, I'd have a channel for the streaming data that is constantly
arriving and a channel for making requests on and getting back answers
immediately. Others could
I really like the model that Voldemort uses for their protocol buffers
implementation. I ported their client to .net and it was really
simple. The framing is really simple as it prefixes an integer value
before binary data. The binary data is a request made with a protocol
buffer, and so is the res
Bruce,
Overall this looks like a good approach to me.
How do you anticipate allocating channels? I'm guessing this would be
one per client object, that a pool of open connections to servers would
be maintained, and creating a new client object would allocate a new
channel.
Currently we per
Hi Bo,
Thanks for your feedback!
On Thu, Apr 8, 2010 at 3:49 PM, Bo Shi wrote:
> Hi Bruce,
>
> Would this RPC protocol take the role of the transport in the Avro
> specification or would it replace the protocol? If the handshake
> occurs on channel 0 while the request/response payloads are
> t
Hi Bruce,
Would this RPC protocol take the role of the transport in the Avro
specification or would it replace the protocol? If the handshake
occurs on channel 0 while the request/response payloads are
transferred on a different channel, this would not meet the existing
wire protocol as described
While I recommend actually reading RFC 3080 (it is an easy read), this
summary may help...
Framing: Length prefixed data, nothing unusual.
Encoding: Messages are effectively this:
enum message_type {
message,// a request
reply, // when there's only a single re
I'm assuming that the goals of an optimized transport for Avro RPC are
something like the following:
* Framing should be efficient, easy to implement.
* Streaming of large values, both as part of a request and as a response is
very important.
* Being able to have multiple concurrent requests in
20 matches
Mail list logo