Re: [hybi] Framing Take VI (a compromise proposal)

[Greg Wilkins <[e-mail]>]

2010/8/16 Ian Fette (イアンフェッティ) <[e-mail]>:
> On Sun, Aug 15, 2010 at 8:44 PM, Greg Wilkins <[e-mail]> wrote:
>>
>> Ian,
>>
>> thanks for the proposal.
>>
>> It appears that the total message length is mandatory if fragmentation
>> is used, however I believe that one of the use-cases for fragmentation
>> is to send dynamic messages where the total length is not known in
>> advance.   Could we make message length optional somehow?
>>
>
> It is optional. %x0000000000000000 ; complete message length is unknown (iff
> initial==1 && final==0) -- suggestions as to how to make that clearer most
> welcome.

Sorry my bad. I see it in the BNF now.

It does feel a little funny to be byte squeezing other lengths and
then to send 8 zeros to say unknown.  To be consistent, we should
either just always send lengths in full or always make an attempt to
squeeze.



>> Alternately, message length (in bytes and/or in characters etc.) is
>> just one example of meta-data.  Would it not be possible to support
>> that in a standardized meta data extension?

any thoughts on this?

>> If we are to have per frame extension data, then I think having the
>> extension length in the header so simple implementations can skip is a
>> good approach.  However, I think we probably would also need to goto
>> extra detail about how data from multiple extensions would be
>> separated within the extension data.
>>
>> However, I remain a little concerned that having both op-code and per
>> frame extension data could result in some contradictory data.  For
>> example, if we have an op-code for final frame, then it is likely that
>> intermediaries will know that frame and possibly use it as part of
>> shutting down the connection (with half closes etc.).  If we then have
>> an extension that provides multiplexing and allows a channel ID to be
>> associated with every frame, what does it mean to have a final frame
>> op code extended with a channel ID?
>
> I would assume it means that a complete message has been sent, but that the
> channel remains open. E.g. I have two channels open, the fact that I've sent
> a complete message on one channel shouldn't be taken as an indication that
> I'm done sending messages on that channel. Even in the non-multiplexing
> case, the fact that you've received a full message doesn't mean the
> connection should be shut down. That's the point of "persistent" :)

Sorry I think you have misunderstood my scenario.  By Final frame, I
was not meaning the final frame as indicated by the bit in your frame
header, but the final frame op-code that we have previously discussed
as one of the potential op-codes (text-data, biinary-data, ping, pong,
final frame, etc).   The final frame op-code has been proposed to half
close a connection - ie no more frames will be sent after a final
frame.  There is such an op-code in the current -00 proposal already.


So to restate my concern, I'm worried that per frame extension data
and core protocol op-codes may not be entirely orthogonal. Some
extensions may be very meaningful for some op-codes, but not others.

To flip this around to a question - can you say why you need extend
every frame?   if there are ping, pong and final frame op-codes
defined, what is the use-case to extend them?  I can see the good
use-cases for extending frames with text and binary op-codes, but that
could be done with just a extended-text and extended-binary op-code?

cheers