[hybi] Technical feedback. was: Process!

[Greg Wilkins <gregw at webtide.com>]

Justin Erenkrantz wrote:
> so I applaud Greg for trying to speak up while also
> getting Jetty to speak WebSocket.

The process of implementing WebSocket and using it within cometd
has been very illuminating.

Once you get paste the strange language of the spec, the protocol
is pretty easy to implement.

It was a little silly having to implement two framing mechanisms
when only one of them has an API to enable it's usage.

We're currently updating cometd to optionally use websocket and
the amazing this is how little it changes (or improves) the
resulting protocol.

Because there is no "buy-in" from intermediaries, we have no
way of knowing how long they will keep open an idle connection.
Because there is no meta-data, we have no idea how long a browser
will keep an idle connection.

So we have to send keep alive messages over the websocket
to make sure it is not closed.  For this we are just using
the /meta/connect message we use for long polling over XHR.

Because there is no orderly close mechanism, we have to keep
our own close handshake and implement our own acks for our
reliable messaging extension (which currently batches acks
into the equivalent of a long poll.... I guess we could
re-invent TCP inside websocket and do message by message
acks... but what a waste!).

So if you look on the wire of cometd running over websocket,
it just looks like long polling.  We use the same /meta/connect
long poll message as a keep alive and as our ack carrier.

We've saved 1 connection, which is great.   But I fear that
saving will be eaten up by the ability of application developers
to open any number of websockets.

If we are not running in reliable message mode, then we don't
need to wait for a /meta/connect before sending a message
to the client, so we get a small improvement in maximal
message latency for current usage and a good improvement
for streaming usage.

But as I've frequently said, it works ok, but it solves
few of my real pain points as comet vendor and it's
caused me more code/complexity not less.

It's not provided any semantics that would allow
any cometd users to consider going directly to websockets
instead of using a comet framework.   Sure it makes sending
messages easy, but that is always easy. It does not help
for when you can't send messages or when connections drop
or servers change etc.   These are all the realworld things
that must be dealt with and ws makes this harder not easier.

It will make cometd usable for a few more use-cases, but
for the vast majority of cometd users, it will be a
transparent change under the hood that makes no significant
difference and I'm left wondering what all the fuss is
about.


regards