Re: [hybi] Technical feedback. was: Process!

[Justin Erenkrantz <[e-mail]>]

On Mon, Feb 1, 2010 at 3:48 PM, Ian Hickson <[e-mail]> wrote:
> On Fri, 29 Jan 2010, Justin Erenkrantz wrote:
>>
>> Again, this is why the current draft is so impenetrable (to me) since it
>> expects that the only person implementing the draft is a client vendor
>> using synchronous socket methods...which sort of defeats the purpose
>> when you are trying to write a fully async client...or any type of
>> server.
>
> Could you elaborate on this? I looked for text that assumed synchronous
> socket methods but couldn't find any. Could you quote the offending text?

All of them are...such as:

---
          Run these steps.  If at any point during these steps a read is
          attempted but fails because the Web Socket connection is
          closed, then abort.

          1.  Let /length/ be zero.

          2.  _Length_: Read a byte, let /b/ be that byte.

          3.  Let /b_v/ be integer corresponding to the low 7 bits of
              /b/ (the value you would get by _and_ing /b/ with 0x7F).

          4.  Multiply /length/ by 128, add /b_v/ to that result, and
              store the final result in /length/.

          5.  If the high-order bit of /b/ is set (i.e. if /b/ _and_ed
              with 0x80 returns 0x80), then return to the step above
              labeled _length_.

          6.  Read /length/ bytes.

          7.  Discard the read bytes.
---

Greg pointed out issues as to what "send" or "receive" means -
buffering, etc, etc.

The algorithmic descriptions can only be precisely followed when you
write a synchronous client (or server) - the algorithms for an network
async read or write framework would appear hugely different.  Again, I
think this challenges the usefulness of specifying the protocol in
pseudo-code when many (optimized?) implementations won't be able to
follow those same algorithms.  -- justin