Re: [hybi] Framing take IV

[Ian Fette (イアンフェッティ) <[e-mail]>]

On Tue, Aug 3, 2010 at 8:29 PM, Maciej Stachowiak <[e-mail]> wrote:

>
> On Aug 3, 2010, at 8:06 PM, Greg Wilkins wrote:
>
>
> On 4 August 2010 12:41, Maciej Stachowiak <[e-mail]> wrote:
>
>>
>> On Aug 3, 2010, at 6:29 PM, Greg Wilkins wrote:
>>
>> But if you have a counter proposal that you think might satisfy the
>> hummers, please make it.  The current protocol certainly does not.
>>
>>
>> Without knowing the rationale of any given hummer, I cannot predict what
>> they would find satisfactory. I hope I have explained enough of my reasoning
>> that others can guess whether a proposal would seem good me. Mandatory
>> chunking for large messages does not sound good.
>>
>
> Maciej,
>
> These entire framing threads a have been about trying to reach a consensus
> on the concerns of the hummers  while coming up with a proposal that will
> seem good to you.  I for one have been really trying to keep the complexity
> to the minimum and have constantly referred back to the work needed for a
> minimal client and server.    I accept that you are not convinced about
> fixed lengths and fragmentation, but then you've not managed to convinced
> others of the contrary and are not coming up with counter proposals that
> might let us move forward.
>
>
> I not only am not convinced, but I produced arguments to support my
> position, which so far no one has replied to.
>
> I'm not saying that your arguments for arbitrary length frames are without
> merit (and the first of my frame proposals did use the variable length
> frames). But if I were the chairs, I would be calling the consensus on the
> side of fixed length and fragmentation.  I guess we can do nothing other
> than put our proposals and wait for a consensus call from the chairs.
>
>
> Seems pretty weak to me to declare "consensus" on a proposal where the
> supporters have not addressed the counter-arguments. To be fair, I only
> posed my arguments against just now, so we should probably wait a reasonable
> time for anyone with a stake in the issue to reply.
>
>
>>    - fragmentation prepares the ground for future extensions for
>>    multiplexing and flow control.
>>
>> I'm not assuming we will need such extensions until we have data to back
>> it up.
>>
>>
> There has already been many sources of evidence that multiplexing is a
> necessary extension for many environments.  You simply don't agree with that
> evidence.
>
>
> I've seen claims that it is needed, but I haven't seen evidence for those
> assertions. I admit with the recent high volume of mail on this list, I
> haven't read every message carefully, so if there's anything I missed that
> presents evidence, could you please give me a pointer?
>
> Still, I think multiplexing is at best an argument for optional chunking,
> not for mandatory chunking of all large messages.
>

In the interest of moving towards consensus, I will say that I believe so
long as the protocol is sufficiently extensible such that things like
multiplexing and chunking can be implemented in an extension (and we are
able to actually implement such an extension in Chrome to start getting
real-world data), then I think I don't have such a strong feeling about
fixed- versus variable-length encoding. However, that depends on having some
sane extensibility mechanism, and an openness to such extensions in WebKit
;)


>
>
> However, consider the four possibilities:
>
> 0) you are right about the need for multiplexing and the framing mechanism
> is not capable of well supporting it
> 1) you are right about the need for multiplexing and the framing mechanism
> is capable of well supporting it
> 2) you are wrong about the need for multiplexing and the framing mechanism
> is not capable of well supporting it
> 3) you are wrong about the need for multiplexing and the framing mechanism
> is capable of well supporting it
>
> outcomes 0,1 & 3 are good outcomes.  2 is a problematic.
>
>
> I don't think these are the only relevant considerations. There is also the
> cost in the case where multiplexing is not used.  That's relevant both if
> multiplexing turns out to be unnecessary, and for services that choose not
> to use multiplexing even if some use it.
>
>
As I said on another thread, this could perhaps be re-phrased as to "what is
the cost of an extensibility mechanism that would allow for e.g.
multiplexing in an efficient manner" which might be a way to look at things
that will help us get to consensus.


> Regards,
> Maciej
>
>
>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>