Re: [hybi] Frame size

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:
> On Fri, 16 Apr 2010, Thomson, Martin wrote:
>> Proposal:
>>
>>  - Frame size is indicated up front.
> 
> This seems incompatible with the requirement that we not expose amateur 
> programmers to the complications of measuring UTF-8 strings.

I'm not this is an agreed requirement.

At the 77 meeting, we asked you to put this into the form of some
proposed text for the requirements document.  We can then discuss
and if there is consensus it can be added as a requirement.

However, I maintain my belief that amateur programmers will
most likely be using frameworks, libraries and servers that
implement the protocol for them.


>>  - Frame size be strictly limited (2 octets should suffice).
>>  - Sub-protocol needed if messages are larger than the max frame.
> 
> This seems like it would make the API highly unpredictable. For example, 
> it would mean that you could transmit 65,536 characters if they were the 
> character "X", but only 21,845 if they were the character U+263A.

Frames are entirely different entities to messages.
The application API deals with message - which if we have a fixed
frame size, may be fragmented and reassembled.

If we did agree on a small fixed frame size, the fragmentation
and aggregation would be an obvious extension.  We may or may not
decide that all clients/servers should implement it.   I think
optional would be best, as browsers are capable enough to implement
the option, but small special purpose clients/servers could be developed
without that complication.


> That 
> would be very confusing. Similarly, if we add compression, it would mean 
> that how many bytes you could pass in the send() method would depend on 
> how well it compressed. This would result in a very bad programming 
> experience, especially for anyone new to this kind of thing. (I would 
> expect most subprotocols to be ridiculously primitive; asking amateurs to 
> figure out chunking mechanics is non-trivial, especially if they have to 
> work out where to split a UTF-16 string as exposed in JS, before it is 
> converted to UTF-8 and compressed, which is what matters for deciding what 
> will fit in the frame.)

The bad programming experience is a result of directly exposing a
protocol entity (frame of binary data) to the application programmer.

The solution is to abstract the application programmer away from
the protocol. They send/receive arbitrary length messages in characters,
the protocol then arranges to encode those as 1 or more binary frames,
with or without compression, with or without aggregation etc.

At the other end, the character message is reassembled (or streamed
to disk if it is large etc).

>> Binary frames isolate user-space (the payload) from the framing layer.  We had this discussion in the meeting (c.f. Pete Resnick's comments).  Thus, 
>>  - binary frames are easier to process (intermediaries don't have to inspect every octet)
>>  - kinder on implementations (framing component does not depend on UTF-8 component)
>>  - isolates framing layer from the bugs of higher layers
> 
> If we were designing a protocol for experts, I would completely agree. 


I believe the vast majority of people here agree with the view that
the target audience for websocket is Browser developers and Server Developers.
ie expert developers.

I know you do not agree with this, but I do not believe that you have made
your case that amateur programmers are the prime target for this protocol.

Have a look at http://en.wikipedia.org/wiki/Web_Sockets - there are
plenty of implementations listed there, which are written by expert
programmers.

Again, if you believe that targeting amateur programmers is a requirement
for this working group, can you propose some text to that effect
to add to the requirements document.   If you make your case, then
it can be included.





regards