Re: HEADERS and flow control

Martin et al,

I really see the problems and confusion in this thread as another example
of the complexities and problems that result when you "conflate some of the
stream control functions with the application semantics functions in the
interests of efficiency."

The definition of streams should be simple and robust and entirely
independent of the semantics of the content of the streams.    A stream
should be defined to exist from the time it ID is first mentioned (either
in a frame ID or a PP) until frames have been sent in both directions with
an end frame bit set.    Between those two events, the stream should be
flow controlled regardless of content.

Once you have robust multiplexed framing, then you can layer HTTP semantics
on top of that.   If a client wants to avoid the dispatch of its requests
from being deferred, then it should just restrict it's headers to < the
stream window size.

I think the hpack tail is really wagging this protocol dog!

Currently hpack is forcing this protocol to have a user accessible non flow
controlled un-segmentable size unlimited meta data streams that has strict
ordering criteria resulting in significant parallel slow down.

Our experience with SPDY is that the vast majority of the speed up comes
from avoiding round trips rather than compression.    This means you need
good multiplexing and good push mechanisms.  Compression is worthwhile, but
I suspect that 90% of the gains can be achieved with a far simpler
algorithm that does not impose such onerous constraints on the framing.

again apologies for giving these opinions late in the process.

-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.