Re: SYN_REPLY

I think that is more related to the discussion in the other thread, and
probably should be discussed there, no?


On Wed, Feb 27, 2013 at 11:17 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> If you like.  This hasn't addressed the unidirectional piece though.
>
> On 27 February 2013 11:16, Roberto Peon <grmocg@gmail.com> wrote:
> > Shall I take that as an agreement? :)
> > -=R
> >
> >
> > On Wed, Feb 27, 2013 at 11:07 AM, Martin Thomson <
> martin.thomson@gmail.com>
> > wrote:
> >>
> >> Opcode or flags, it matters not.  It depends on where you want to
> >> spend your bit (or part thereof).
> >>
> >> On 27 February 2013 10:45, Roberto Peon <grmocg@gmail.com> wrote:
> >> > The we're wasting bytes on responses. Bleh. Worse, now we can't simply
> >> > examine the length field to figure out what to do. Double-eww.
> >> > In any case, spending a bit in the flags, is far more costly than
> >> > spending
> >> > the fractional bit out of the opcode space, which is what is done
> today!
> >> >
> >> > Something I could go with, given the previous change would be to also
> >> > change
> >> > the name of SYN_STREAM to HEADERS_WITH_PRIO
> >> > and leave HEADERS as it is.
> >> >
> >> > How does that sound?
> >> >
> >> >
> >> > -=R
> >> >
> >> >
> >> > On Wed, Feb 27, 2013 at 10:20 AM, Martin Thomson
> >> > <martin.thomson@gmail.com>
> >> > wrote:
> >> >>
> >> >> On 26 February 2013 20:16, Roberto Peon <grmocg@gmail.com> wrote:
> >> >> > Taking the priority out of SYN_STREAM would only bloat things on
> the
> >> >> > wire,
> >> >> > since the client will always want to state priority for a new
> stream.
> >> >> > I
> >> >> > don't support removing priority from SYN_STREAM.
> >> >>
> >> >> What if HEADERS contained priority?  Is your objection to removing
> >> >> priority from SYN_STREAM, or removing priority from the first frame
> in
> >> >> the stream.
> >> >>
> >> >> Here's a more concrete proposal, albeit slightly radical.
> >> >>
> >> >> Remove SYN_STREAM and SYN_REPLY.
> >> >> Have stream-level flags that appear in ALL messages.
> >> >>  1. last frame in stream (the existing FIN bit)
> >> >>  2. stream priority (a new one)
> >> >> The 'stream priority' flag indicates that the first 4 bytes of the
> >> >> frame payload includes a priority.  This should (or SHOULD) be set on
> >> >> the first frame of any stream.
> >> >>
> >> >> Then a typical stream looks like:
> >> >>  - a HEADERS frame with the 'stream priority' flag set, plus a
> priority
> >> >>  - a bunch of data frames
> >> >>  - maybe some other frames
> >> >
> >> >
> >
> >
>