Re: [hybi] Random Responses

Yes, BEEP does fit the requirements discussed so far ... (not to mention support for flow control which becomes immediately necessary in bi-directional streams).

Flip side would be, I am not sure if it is upgradable from HTTP with current infrastructure - other than through CONNECT that is.

Regards,
Mridul

--- On Sun, 12/4/09, Greg Wilkins <gregw@webtide.com> wrote:

> From: Greg Wilkins <gregw@webtide.com>
> Subject: Re: [hybi] Random Responses
> To: "Mark Lentczner" <markl@lindenlab.com>
> Cc: hybi@ietf.org
> Date: Sunday, 12 April, 2009, 7:57 AM
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
> 

      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/