Re: [hybi] WS ABNF

[Scott Ferguson <[e-mail]>]

Dave Cridland wrote:
> On Wed Feb 17 17:03:42 2010, Scott Ferguson wrote:
>> This isn't complicated.
>
> Yes, yes it is. It's hugely more complex than it has any right or 
> reason to be.

It's something like 6 lines of code to parse.  I don't consider that 
hugely complex. Even parsing an HTTP chunk length is more complicated 
than this.

>>  Just use a chunk/fragment encoding that looks like
>>
>>  len ::= [\x80-\xff]{0,3}[\x00-\x7f]
>>
>> The 0-terminating chunk takes up a single byte, small messages (< 
>> 128) only need two bytes of overhead, chunk lengths are limited to 
>> 32-bits (actually 28-bits but it doesn't matter), the total message 
>> size is arbitrarily large, and it's trivial to implement.
>>
>>
> Not even remotely as trivial as encoding it as a 32-bit network byte 
> order integer. My point is that a compact representation is, here, 
> simply not needed. In UTF-8, it *is* needed, because the potential 
> savings are 75%, but here, the message itself is the bulk of the 
> transfer, and there is no point in wasting effort in making length 
> encoding harder than it needs to be to save a percentage point or two.

The complexity is essentially the same. I agree that the savings are 
trivial, but the implementation is trivial as well.

>
>> If it's important to add message types (and that would be cleaner as 
>> a different layer), that's just a single extra byte of overhead.
>
> As I read it, there are already message types. I'm not wed to them 
> being there, although I can see the utility of having message types 
> and identifiers at a relatively low level. (It's useful both in BEEP 
> and XMPP, for example).
Well, XMPP isn't exactly low-level :)

-- Scott
>
> Dave.