Re: [hybi] WS framing alternative

[Pieter Hintjens <[e-mail]>]

On Mon, Nov 2, 2009 at 10:39 PM, Greg Wilkins <[e-mail]> wrote:

> I really like the phrase "a tool for understanding the design space",
> and believe that it entirely applies to BWTP.
>
> However, I don't think there is a consensus that the same applies
> to websocket.   Unless understanding tools include something that
> get's deployed in the wild, causes all sorts of problems and then
> makes people realize the errors once it is too late to take it back.

Yes, that's a common enough failure pattern.  We have no control over
how others view and develop their protocols and anyone trying to
standardize at the same time as they experiment and learn will just
end up paying more for their lesson.

I'd reinforce Roy's assertion that what counts is implementation and
the quality of the specification, and that standardization comes when
the experimentation and learning is over.

The core issue here is, IMO, status and territory and there is an
apparent conflict over positioning in the IETF of a single protocol to
accomplish something... unstated... but which somehow makes HTTP work
better.  BWTP solves one set of problems: asynchronous high-volume
delivery as an upgrade of HTTP.  WebSocket solves another set, which
I'm not clear on but which clearly are not reconcilable.

We can set aside the status/territory discussions and just consider
how to ensure that BWTP works well.  WebSocket is the problem of its
designers, who seem to have strong notions of what they need.

Which means a clear spec (that we have), a cheap way to access it and
improve it (which we have) and a small but growing community of
developers and implementors.  We can assume that a well-written and
widely-used spec will get formal adoption when that makes sense.

I'd like to see this WebSocket vs. BWTP discussion end, and the energy
going into prototype code, use case documentation, and community.

-Pieter