Subject: Re: [Ppm] Making long-running requests asynchronous

From: Tim Geoghegan <[email-masked]>
Date: Mon, 28 Feb 2022 17:35:14 -0800

Thanks for that excellent advice and the links, Martin!

I've just pushed a pull request that makes the `CollectResp/CollectReq`
portion of the protocol asynchronous. Those changes can be seen on GitHub
<https://github.com/abetterinternet/ppm-specification/pull/193>. Any
feedback is welcome, either here in email or on GitHub.

Thanks,
Tim Geoghegan
ISRG

On Mon, Jan 24, 2022 at 7:30 PM Martin Thomson <[email-masked]> wrote:

> Hi Tim,
>
>
> On Tue, Jan 25, 2022, at 13:30, Tim Geoghegan wrote:
> > I'd love to hear thoughts on what the established best practices for
> > long-running tasks in HTTP APIs are.
>
> Maybe this might help you:
> https://httpwg.org/specs/rfc7240.html#respond-async  (URIs, not UUIDs)
>
> You might also find this informative:
> https://www.rfc-editor.org/rfc/rfc8820.html
>
> You are probably familiar with how ACME does asynchronous processing,
> which is largely OK.
>
> > What kind of heuristics usually inform whether or not to
> > make an API asynchronous? Should we make these messages async just in
> > case it ends up being useful in the future?
>
> This probably comes down to preference at some level.  However,
> asynchronous interactions are a fair bit more complex than synchronous
> ones, so avoiding that complexity is good.  Keep in mind that modern HTTP
> versions aren't stalled if there are a handful of long-running requests, so
> unless you are talking a fairly significant time, it might be cleaner and
> easier to just have the client wait on hold.
>
> Asynchronous requests do come with some benefits to go with the
> complexity. For instance, robustness can be improved if the initial request
> creates resources that can be referred to later on a different connection
> without having to rely on the connection remaining viable.
>
> RFC 7240 does suggest that you might offer both, but I would only go that
> far if you thought that implementations would consistently use both options.
>
> --
> Ppm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppm
>