Re: [hybi] ws and bwtp thoughts

[Greg Wilkins <[e-mail]>]

Martin,

Thomson, Martin wrote:
> I've been following the discussions on WS and BWTP (awful name, BTW) with some interest.
> 
> The differences are many, but aside from a few they probably make little difference from a technical standpoint.

I totally agree.

Most differences between BWTP and Websocket a non-semantic

For example websocket encodes length in a binary integer of arbitrary
length, while BWTP uses a ascii decimal number of arbitrary length.
The difference is pretty much just a style choice.

I think websocket can be improved to have the capabilities
I'm advocating and the other differences are not important.
See my blog on this exact subject:

   http://blogs.webtide.com/gregw/entry/how_to_improve_websocket



> ==Channels
> Channels are not the issue - ...
> Channels are just one way of addressing the problem.

+1

Channels are just a means to an end and not an end in
themselves.


> Delegating any responsibility to a higher layer is
> another way.

That depends what you think is "the problem". :)

I consider the problem is that applications should
not have to manage TCP/IP connections nor have the
ability to directly request them.

I don't think delegating to a higher layer solves
this problem.


> HTTP doesn't have channels.  There's no multiplexing.  
> If you need multiplexing, you open a new connection.

HTTP does support multiplexing - but not with channels.

If you open another XHR in js, the browser will look
for an idle connection, which may have been opened
by another application in another frame/tab/window
(or in same frame, but previous page).

Also there are proxies and other intermediaries that
multiplex many clients onto shared connections.


> So I have a (half-baked) suggestion: Use MIME and 
> allow requests to be addressed.

If by "request" you mean "message", that is indeed
another possible solution abstract away from the
actual TCP/IP connections - and is probably simpler
than channels.

However, like HTTP, you would need some meta data
with each and every message.

If you are concerned about reducing data usage,
then channels (or at least BWTPs implementation of them)
allows meta data to be sent only once per channel
and then each message can be just data and no meta
data.

If you are less concerned about data usage, then
meta-data per message works ok for HTTP



But your  point is well taken.  There is more
than one way to skin a cat - and we should be
prepared compromise on the means we use to
achieve the outcomes that we want.

cheers