Subject: [hybi] complexity explosion

From: Justin Lee <[email-masked]>
Date: Wed, 18 Aug 2010 10:11:10 -0400

I'll preface this by saying, I only just joined the list a day or two ago.
 I'm the implementor of websockets in grizzly/glassfish and have been
following the evolution of the spec for not quite a year now.  My initial
read and implementation was around the -68 version or so.  Give or a take a
rev.  It was simple and useful.  -76 brought a more complex handshake which,
while bit ... heavy handed in its result, made a certain amount of sense.
 But I have to say that I watch the current wrangling over protocols updates
horrifying.  It seems *horrendously* complex and I shudder at the thought of
trying to implement all this.  I haven't seen all the arguments for/against
some of these changes (though I'm trying to get up to speed) but as an
implementor I just have to say that all this sudden complexity is truly
depressing.  It actually reminds of the initial EJB discussions where "what
ifs" and "what abouts" lead to an egregiously complex spec that nobody
really liked.  I'd love to see a renewed focus on simplicity.

-- 
You can find me on the net at:
http://www.linkedin.com/in/justinlee
http://www.twitter.com/evanchooly

---

From: John Tamplin <[email-masked]>
Date: Wed, 18 Aug 2010 10:13:43 -0400

Can you describe what you find horrendously complex about recent proposals?

---

From: Justin Lee <[email-masked]>
Date: Wed, 18 Aug 2010 10:22:28 -0400

Well, for example, the framing discussion.  At 64 bits, that's still crazy
large.  Hell, move it up to 128 if you really want to support sending full
movies via on websocket frame.  All this back and forth about partial this
and multiplexing that.  It's really starting to gum things up.  But like I
said, I'm still trying to get my mind around all the arguments.  Perhaps
there really are valid reasons for it all but it's taking websockets from a
simple spec to something that looks more like trying to reengineer TCP.

---

From: John Tamplin <[email-masked]>
Date: Wed, 18 Aug 2010 10:53:42 -0400

On Wed, Aug 18, 2010 at 10:22 AM, Justin Lee <[email-masked]> wrote:

> movies via on websocket frame.

When you read back over the discussions, you will see that there are in fact
people who wanted to send a full DVD movie in one frame, so they could just
had it off to the kernel.  The v76 protocol supported an arbitrary number of
bits of length, so you had to be prepared to handle multiprecision
arithmetic to properly implement the spec -- at least now you know you need
a fixed 64-bit integer.

> All this back and forth about partial this and multiplexing that.

Note that multiplexing specifically will not be included in the base
protocol.  The discussion about it is so that we can add it later without
having to break backwards compatibility, which means that you implementing
v1.0 of the spec won't have to worry about it ever unless you actually do
want to participate in multiplexing.  Fragmentation has been accepted as a
requirement of the base protocol, partly to support later extensions, so
that is complexity you will have to deal with, but it really shouldn't be
that bad.

To implement the current proposal, if you never negotiate any extensions
during the handshake then it is simply a length, an opcode, and
fragmentation flags, and if the short length is 127 then you read the long
length, and then the payload bytes.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Justin Lee <[email-masked]>
Date: Wed, 18 Aug 2010 10:57:43 -0400

OK.  That helps to know.  That's a nice summary.  I hadn't been able to
glean that from the discussion so far.  Thanks for the clarification.

On Wed, Aug 18, 2010 at 10:53 AM, John Tamplin <[email-masked]> wrote:

> When you read back over the discussions, you will see that there are in
> fact people who wanted to send a full DVD movie in one frame, so they could
> just had it off to the kernel.  The v76 protocol supported an arbitrary
> number of bits of length, so you had to be prepared to handle multiprecision