On Fri, 5 Jun 2015, Lucas Pardue wrote:

> The suggestion looks good on first inspection. I had a questions without
> much time to think of answers sorry:

No worries. I think you're being too modest, I apprecite them a lot! I need
more eyes and brains on the problems than just my own.

> 1) What about the "post-transfer" state? Should Section 6.3 of the spec says
>
> "The PRIORITY frame can be sent for a stream in the "idle" or "closed"
> state. This allows for the reprioritization of a group of dependent streams
> by altering the priority of an unused or closed parent stream."
>
> It seems a bit horrible to have to keep "old" easy handles laying around in
> order to support this possibility.

Yeah I agree. Thanks for putting the light on this complication.

Not only do we need to keep the easy handle around for this, we also need to
keep it "active" sort of so that we can send HTTP/2 frames on that stream to
allow this.

I could imagine that as long the application hasn't yet removed the handle
from the multi handle, it could theoretically still be used for this even
post-completion of its request. I just feel like a use case I'm not eager to
work on and I think I'd rather document as unsupported for now. Then someone
who feels strongly for this can still work on adding it later. Possibly myself
of course, just later on.

> 2) CURLOPT_STREAM_DEPENDS_ON validation could be tightened up to return
> error if attempting to depend on self. Maybe it already does, in which case
> it would be good to document.
>
> "A stream cannot depend on itself. An endpoint MUST treat this as a stream
> error (Section 5.4.2) of type PROTOCOL_ERROR."

Right, in our case we can make sure immediately that the user doesn't pass in
its own handle. Added a mention of that now.

> 3) How about dependency exclusivity?

Oh, I forgot that thing... (I can already see how documenting this to libcurl
users is going to get tricky.)

I wonder how we should best pass in the "exclusive flag" for a stream. One way
I can think of is to offer a separate exclusive dep option called
CURLOPT_STREAM_DEPENDS_EXLUSIVE or something. It would set both the "Stream
Dependency" and the "E" fields and the other option would clear the "E" field.

> If someone inserts an exclusive dependency into an existing tree it will
> change the parent stream of the existing dependents. Figure 4 in section
> 5.3.1 shows an example. Should there be a way for the user to interrogate
> the dependency parent of a handle, or to inform them of changes via a
> callback?

The client is in full control of what stream dependencies it sets so there
should be no surprises, right? I don't see how a callback or similar is needed
for this. Or did you have something special in mind?

> 4) With the server push API using the term "parent" things could get a bit
> confusing. It is more like "push parent" and "dependency parent" but that
> sounds a bit ugly.

Yeah. The HTTP/2 spec only speaks of "dependency" and never parent when it
speaks of dependencies so maybe we should too for consistency and reduce the
risk of confusion. This is however "only" a matter of documentation which
makes it a bit easier and we can polish it over time.

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