Re: SYN_REPLY

s/resource/request.
*sigh*
-=R


On Thu, Feb 21, 2013 at 4:38 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Browsers are *extremely* likely to use this, and they're where we're most
> bandwidth constrained.
> The goal is to allow the browsers to emit requests as soon as they're
> encountered. I think that the resource types encountered often intermix, so
> requiring a PRIORITIZE frame and a HEADERS frame together seems a waste of
> resources on the link most likely to be the bottleneck.
>
> Worse, to get proper behavior out of the server, you'd have to set the
> priority before sending the resource. Assuming that the PRIORITIZE frame
> sets a per-stream priority, this is not great, as it requires the server to
> keep additional state about a stream that hasn't yet arrived. If one sets
> the priority on stream zero, we could argue that this is setting a default
> priority for all streams (though that'd be new), which solves this problem,
> but only over a TCP channel-- mapping to SCTP would again become
> problematic and rac-y.
>
>
> -=R
>
>
> On Thu, Feb 21, 2013 at 4:31 PM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> :)
>>
>> SYN_STREAM would be next on the list of targets.  Removing that would
>> require a PRIORITIZE frame and (maybe) a setting to establish a
>> default stream priority.  The downside is that it would add 4 bytes to
>> streams where a non-default priority was desired.  Saving 4 bytes on
>> the default priority might not be a good enough trade-off.
>>
>> For my use cases, I don't care about prioritization for most requests,
>> so that would be a good trade-off.  I'm sure that browsers are more
>> likely to have a highly variable priority for resources, so it might
>> be a bad trade-off.  That is, if you cared more about the bits than
>> the ability to remove another whole frame type.
>>
>> On 21 February 2013 16:09, Roberto Peon <grmocg@gmail.com> wrote:
>> > Indeed, on re-reading the first message, that is what you're proposing.
>> >
>> > Seems reasonable to me.
>> > -=R
>> >
>> >
>> > On Thu, Feb 21, 2013 at 4:07 PM, Roberto Peon <grmocg@gmail.com> wrote:
>> >>
>> >>
>> >>> > SYN_REPLY doesn't have one, because it doesn't need to declare
>> >>> > priority--
>> >>> > the SYN_STREAM already did that, and it is almost always a waste to
>> >>> > include
>> >>> > a priority field in SYN_REPLY.
>> >>>
>> >>> Agree.  So what does SYN_REPLY actually do then?
>> >>>
>> >> It contains a HEADERS block and little else. If you're arguing to elide
>> >> SYN_REPLY given HEADERS, then sure, I can see that-- the frame fields
>> are
>> >> the same now that we've removed the 'in-reply-to' field.
>> >>
>> >> -=R
>> >
>> >
>>
>
>