TAPRegExt: sync/async preference

[Mark Taylor]

Markus et al.,

[I have followed up to the dal list only and not to registry
to reduce noise and confusion; DAL anyway owns TAPRegExt as
well as TAP]

On Mon, 7 Jul 2025, Markus Demleitner via registry wrote:

> Basically, Rubin would like to be able to tell TAP clients: "Prefer
> async mode on this service".  I can totally see how, say, TOPCAT,
> could pre-set the Mode combo box based on that, and that's enough to
> convince me it's a sensible feature.

Before offering an opinion, I'd like to understand better exactly
what Rubin or other services might mean by "prefer async mode",
or why they might want to express that.  Does it really mean
"sync is deprecated here, and although we implement it because
it's mandatory in the spec there's some reason why it's really
a bad idea to use it for this service", or just "sync imposes
limits that mean long-running queries may not complete"
(which is anyway generally understood for sync)?

For instance when topcat first hits a TAP service one thing it
does is issue the following synchronous query:

   SELECT COUNT(*) AS nrow FROM TAP_SCHEMA.columns

so it can figure out whether it's a big or small service to
inform some later decisions about metadata acquisition.
The strong expectation is that this query (and some other
under-the-hood ones that it makes) is going to execute fast,
so the additional overhead on the client side of making an
asychronous query is an unnecessary burden.

If we implement some way for services to say "prefer async mode"
does it mean that such quickie queries must/should be submitted
async?  On the other hand, if a service says "prefer sync mode",
does it mean that a query I know is going to exceed a normal
HTTP timeout must/should be submitted sync?

Mark

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/