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

[Paul Prescod <paul at prescod.net>]

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