On Fri, 5 Jun 2015, Lucas Pardue wrote:

> Sounds like a good plan. Thinking about the server side, how likely is it
> that they want to hold or process information related to a closed stream? My
> guess is that it is low.

That's my guess too. I think it is better to go with a simple and basic
implementation now and then improve that over time when we learn how servers
use this in actual deployments.

> Can you unset an exclusive dependency? I hadn't thought about that before
> but it seems totally possible.

I actually don't think you can as it isn't a state stored on the stream. The
way I see it, a PRIORITY frame sends an instruction to the other end on how to
change the priority and dependency for that stream. If the 'E' flag is set it
acts on one way, and if it isn't set it acts in a different way. It applies
the instruction two different ways.

In the Figure 4 example in RFC 7540 where 'D' is set Exclusive, it becomes
depending on 'A' while 'B' and 'C' depend on 'D'.

Sending a follow-up PRIORITY on stream D that doesn't have Exclusive set would
only change which stream D depends on, it will not remove the 'B' and 'C'
dependencies from 'D' that it wouldn't have had if it hand't had Exclusive set
in the first place.

> Have you considered that PRIORITY frames can be sent on idle streams? I'm
> not sure if this is already covered by your API suggestion but in essence we
> would want to be able to send a frame without a real request (no HEADERS).

I think I'll consider that another edge case which I'm leaving out as a start.
Also, libcurl doesn't really have idle streams like that. It'll either use
them or they'll go to do closed state.

Thanks for your great feedback!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html