Re: Nit: Server-sent priority

There are usecases but they are not fascinating.

E.g. The server could reprioritize a stream which had been sending video
(or other long download) for a long time at a high priority down to a lower
priority and this might be useful to know.

The case of server push has a clear usecase and little chance of erroneous
infinite loops.
-=R
On Jun 19, 2013 6:16 AM, "Patrick McManus" <pmcmanus@mozilla.com> wrote:

> The only use case I understand, in an HTTP context, for server sent
> priority is on a pushed stream. And in that case the priorities are
> distinctly not independent between the client and server initiated streams
> (though they all apply to the response body sender).
>
> In that case the client has to know the priority the sender is using on
> the new stream (and potentially change it) so that future streams initiated
> by the client can have their priorities set in a relative weigh.
>
> An example: the client requests index.html at priority 3, the server
> pushes img1 and css1. All three resources are still transferring and the
> client now wants to pull img2 and img3 at the same priority as img1 (which
> is still flowing) but a lower priority than css1. What priorities does it
> use in its requests? It can't get that right without knowing what priority
> the server has assigned to those pushes.
>
> Is there another use case here?
>
>
>
> On Wed, Jun 19, 2013 at 4:06 AM, Mike Belshe <mike@belshe.com> wrote:
>
>> Accidentally sent this only to Martin.
>>
>> Looks like James and I had the same answer.
>>
>> ---------- Forwarded message ----------
>> From: Mike Belshe <mike@belshe.com>
>> Date: Tue, Jun 18, 2013 at 5:09 PM
>> Subject: Re: Nit: Server-sent priority
>> To: Martin Thomson <martin.thomson@gmail.com>
>>
>>
>>
>>
>>
>> On Tue, Jun 18, 2013 at 3:42 PM, Martin Thomson <martin.thomson@gmail.com
>> > wrote:
>>
>>> We discussed the possibility that a server could send PRIORITY (either
>>> in its own frame or attached to HEADERS).  The idea was that the
>>> server could advise a client about the priority that it is applying,
>>> which might be different to the priority that a client requested.
>>>
>>
>> I am not sure how the client would use this information.
>>
>> The intent of priority was to indicate what order you'd like the other
>> side to process the streams.  If its a full-duplex stream (not likely
>> HTTP), the server and client can each assign a different priority to the
>> other side.
>>
>> They're just independent.
>>
>>
>>>
>>> This adds a challenge for clients: does the client now provide updated
>>> priorities that are relative to the priorities that it sent
>>> previously, or relative to the priority that the server has indicated?
>>>
>>
>> Indeed confusing - more reason not to do this :-)
>>
>>
>>>
>>> e.g., client sends three requests, priority 7, 10 and 15.  Server
>>> responds and indicates priorities of 3, 5 and 7.  If the client wants
>>> to issue a new request that is higher priority than the lowest
>>> priority existing request, does it indicate a priority of between 10
>>> and 15?  Or does it indicate a priority of 6?
>>>
>>
>> 10< pri <15
>>
>>
>>> This editor wants to know.  I think that the easiest approach would be
>>> to stipulate that the priorities spaces are independent and that
>>> client priorities are only relative to client priorities.
>>> Unfortunately, that means that I need to include the example above as
>>> well.
>>>
>>
>>
>>
>>>
>>> I don't want to prohibit servers from sending priority, because I
>>> believe that it could be useful for a client to understand how
>>> priority is being applied.
>>>
>>
>> I'm not sure how the client would use that information - dynamically
>> adjust?  This seems like a non-use case.
>>
>>
>> Mike
>>
>>
>>
>>
>>
>>
>