Re: [hybi] BWTP Proposal - Bidirection Web Transfer Protocol

[Greg Wilkins <gregw at webtide.com>]

Paul,

with regards as keeping the messages identical to RFC2616, I did consider
this because it would be cool to just work through existing intermediaries.

But the fundamental problem is that because it is request/response
the number of responses must equal the number of requests.  So if you
have traffic that is substantially one way, you end up sending lots
of empty messages the other direction to keep things balanced.  This
degenerates to more-or-less long polling - which we can do today.

I guess there could be an incremental improvement in HTTP long
polling by sending a full pipeline of requests and requiring the
server to examine that incoming pipeline for messages, but there
would be queueing delays and not all intermediaries can handle
pipelines anyway.

Also the websocket guys appear very keen to byte squeeze the packets,
so changing the start-line to include content length was a good
way to achieve this.

Finally, for the sake of debugging, it would be good if a
BWTP protocol packet can be identified as such by inspection without
state.

So that's why I've gone down the path that I have.


But if you think that a pure RFC2616 like approach is worthwhile,
then I'd certainly review and contribute to an alternate alternate
proposal.

cheers


Paul Prescod wrote:
> Could you justify the "non-obvious" changes from RFC2616?
> 
>       The BWTP has been substantially based on HTTP/1.1 and the RFC2616
>     document
>       that specifies it.  The key differences with HTTP/1.1 are:
>         * A BWTP connection cannot be directly established by a client, but
>           must be upgraded from a HTTP connection.
> 
> 
> Okay.
>  
> 
>         * There is no relationship (like request/response) between inbound
>           and outbound messages
> 
> 
> Is this "simplification" worth the cost of being different from RFC2616?
> As we all know, one can implement fire-and-forget on top of
> request/response or vice versa. One could imagine a trivial mod_async
> which merely returns 200 OK to every message before queuing it for
> internal processing. On the client side, async HTTP already exists.
>  
> I also wonder the simplification of the protocol is worth the cost of
> being different for all of the following:
> 
>         * There are no methods or statuses associated with messages. 
> 
>         * Messages may either be completely self describing or rely on meta
>           data associated with the connection that is established during
>     upgrade.
>         * A message content length is included in the message start line
> 
> 
> This one seems necessary:
>  
> 
>         * An orderly close sequence is specified
> 
> 
> WRT:
>  
> 
>         * There is no caching mechanism
> 
> 
> HTTP's caching mechanism is already optional, right?
> 
> One virtue of staying closer to HTTP is that one can easily imagine how
> existing AJAX APIs and code could be adjusted to use the BWTP socket
> easily. For that reason, I am leaning towards the belief that BWTP
> should try to be a superset of unidirectional HTTP.
> 
>  Paul Prescod
>