Re: [hybi] WS framing alternative

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
> It appears that the whatwg want layered protocols to be controlled by
> the allocation of frame byte values to them and only officially
> sanctified extensions will get the nod.

Let's not get confused about what will and won't work.

It doesn't matter whether WHATWG sanctions any new frame type or not:
you can't _use_ a frame type if the other end won't recognise it.

That's because the message boundaries are determined by recognising
the frame type byte, then parsing the message in a type-specific way.

If message boundaries cannot be recognised when an unknown type is
received, a receiver can't do anything more with the connection.  It
just has to drop the connection at that point.

That means any intermediary (which may be just code inside a client or
server framework, or a proxy) will have to pass all all the bytes it
receives as it receives them, with little or no delays, because
intermediaries can't know where a message ends in general, except for
the frame types defined in the first version.

> The Whatwg needs to loosen
> up and realize  that it should not try to completely control how a
> protocol will be used in the wild (eg an not force all servers
> to be 100 line perl scripts).  They have to allow it some room to
> breath and grow.    They need to allocate some space for some
> arbitrary meta data to be used or ignored as implementations see fit.

Implementations can do that themselves.

A curious irony of WebSocket in it's current form is that there's no
reason a particular implementation should bother to use WebSocket
framing, if it doesn't wish to be accessible to Javascript browsers.

Since you must negotiate any custom protocol layered on top of
WebSocket out of band anyway (e.g. by agreeing what is present on some
URL), and because message boundaries cannot be recognised for unknown
frame types, and because there is no way to report per-frame errors,
in general all software which doesn't block WebSocket and intends to
be future compatible must pass the byte stream along verbatim, without
delays.

That means when implementing clients and servers of custom protocols,
you have two choices:

    - You want it to be accessible to Javascript in web browsers (in
      the short term future).  So you must frame everything into UTF-8
      frames, whatever kind of data it is, and define your own text
      protocol within that.

    - You don't care about Javascript in web browsers.  Because you
      know anything forwarding your WebSocket connection which is
      future compatible must pass along arbitrary bytes without
      delays, because there is no generic way for it to know frame
      lengths, you might as well send frame type byte NN (pick a
      number that is not used) followed by raw TCP with your own
      protocol after the upgrade request, if that is convenient.

      There seems to be no reason to use the spec's binary frames, if
      a TCP stream is more convenient for some application.

-- Jamie