Re: [hybi] Random Responses

[Greg Wilkins <[e-mail]>]

Mark Lentczner wrote:
> 
>  I should have said that we have a need for 
> full-duplex request-response -- either side can spontaneously send a 
> request message, and either side can, when ready, reply to a prior request.

BEEP!

> for any complex page, an application is almost certainly 
> going to want a way to address which widget on the page is the intended 
> recipient of the event. Hence, each application is going to have to 
> devise an addressing scheme, and more importantly, a method of encoding 
> that address in the simple string event.

BEEP!

 > I think popularity of HTTP for many kinds of
> applications has shown that one or more features of HTTP(*) are often 
> applicable to an application's needs, while the overhead of these 
> features is low enough to be worth including them in the protocol for 
> all.(**)
> 
>     - Mark
> 
> (*) Addressing (URLs), Method, Headers, Content specification, Transfer 
> specification, Status

BEEP!

> (**) I imagine the wire overhead for putting a minimal string event into 
> an HTTP message would be something like:
>     POST / HTTP/1.1
>     Host:
>     Content-Type:text/plain;charset=UTF-8
>     Content-Length:xxx
> 
> and
>     204 ACK
> That's 96 bytes overhead for a 100 to 999 byte payload. Seems high, but 
> for the usage cases that web pages present, this probably is not 
> relevant.  Further, once one has this framing, it is very likely that 
> rather than build addressing into the string payload, applications would 
> just make use of the URL field. Plus, this framing already has character 
> encoding support.

BEEP!


Generally agreeing with all your points.  Yet the attributes you
describe do sound pretty much like BEEP protocol - or at least
beep framing.

BEEP is very much a HTTP style protocol with addition of
bidirectionality, multiple response requests and multiple
channels over a single connection.

If BEEP was extended with a few default assumptions (eg
UTF-8 text body if no content type specified), then it would
approach the byte efficiency of websocket, while preserving
the extensibility and flexibility of HTTP.

If the security and authentication aspects of BEEP were
stripped, then a pretty simply protocol would remain.


IF I was forced to pick a winner.... then I'd certainly
look very closely at BEEP or a BEEP derivative.


cheers