Fwd: Nit: Server-sent priority

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