Async conventions outside of Processes API

[bilts]

In implementing the Coverages API, it's clear that we need some sort of accommodation of asynchronous requests. There exist coverage requests that we want to fulfill but cannot guarantee completion within any reasonable timeout. Has there been thought toward making the async portions of the Processes API available to other APIs? What would be the mechanism for doing this?

The previous WCPS standard seemed to bridge this gap, but I don't see anything between the new Coverages and Processes services.

[bpross-52n]

There is currently no separate conformance class for async execution in the OGC API - Processes. It is the default execution mode. Howevern this is subject to change, as we plan to also introduce a push-based async execution mechanism (in addition to the existing pull-based one).

In general the question is whether it is feasible for the Coverages API to use a conformance class from the API - Processes or whether the async execution conformance classes should move to the API - Common and Coverages as well as Processes use those..

[bpross-52n]

See also here: https://docs.opengeospatial.org/per/18-045.html#async_extension

[jerstlouis]

I proposed that the async execution / Prefer: header / job management / status polling functionality of processes also be defined as a Common building blocks to use with any OGC APIs, e.g. for large coverage requests
See opengeospatial/ogcapi-common#231 (comment) and opengeospatial/ogcapi-coverages#66 (comment)

[bpross-52n]

Closed as this discussion will happen in API Common.