On Wed, 24 May 2017, Lucas Pardue wrote:

> Has an inversion of the solution been thought out? Rather than expose
> internals for a use case that "everyone" has to implement, why not design a
> libcurl API that embodies this? Thinking aloud, I can imagine some kind of
> "Request if X" API that lets us associate outgoing requests and schedule
> them if criteria X is satisfied (for X as "Host is reachable", "Request
> bytes written" etc)

You mean like when handle Y reaches state X, start transfer Z ? Where X would
be more or less those different states.

That just feels like a very niche feature that we've had very little requests
for. And I suspect it would also lead to many more things needed for it to be
really usable to applications; like what if it doesn't reach the state within
a certain time or what if it ends before it reaches the state how would that
be signalled back to the application? Tricky.

Another approach would be to offer a callback for state changes so that
applications can get told when the transfer state changes and then they could
do whatever they want with that info. A callback seems better to me than just
a getinfo, since if you want to do something special when libcurl reaches a
particular state it's impractical to keep polling the state to detect it...

Of course, even with callbacks we have the problem for when a certain state
isn't reached at all but instead get skipped etc.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html