Re: [hybi] Framing take IV

[Maciej Stachowiak <[e-mail]>]

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.

> 
> 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.

Regards,
Maciej