TAPRegExt: sync/async preference

[Mark Taylor]

On Wed, 9 Jul 2025, Patrick Dowler via dal wrote:

> 1. We more carefully define TAP-sync patterns to make blocking and retry
> a part of the API so clients can be written to deal with it successfully
> 2. We more carefully define TAP-sync to be able to respond with "this
> request is actually
> executing in async mode, here is the UWS job URL"
> ... 
> I think a feature-rich client like topcat and pyvo could also deal
> with option 2 pretty easily, but that
> quickly becomes a lot less true for simple/custom scripts or basic
> command-line usage of curl, etc.

I don't really understand the motivation here.

Is the idea that the existing sync interface continues to work,
but an async-masquerading-as-sync-aware client submitting a sync job 
can switch to async mode if it gets a response with additional 
information (headers?) indicating that it's async really?
If the client is prepared to do that, why not submit an async
job in the first place?  If an unsophisticated client fails to
switch to async mode, the job would presumably continue to execute 
following a client HTTP timeout, consuming resources uselessly.

Or is the idea to respecify the sync endpoint in such a way that
clients have to do more negotiation than just a single POST/GET
yielding a VOTable response?  The existing sync query is really
a nice convenience for quickie clients (e.g. shell scripts)
wanting to do something easy.

To me the existing situation of having two options for submitting
a job works well for clients, and my impression is that users
understand it OK.  Has the understanding of client and server
requirements for short- and long-running jobs changed since
TAP 1.0 was specified with both sync and async endpoints?

If services don't want to work synchronously under the hood they
can provide a sync facade on their asynchronous behaviour,
which I believe is what some implementations do already.

I would also actually say it's a feature (though maybe an unintended 
one) that sync jobs typically time out before too long, indicating 
that the submitted query is actually expensive, which may not be
obvious to the ADQL author.

Mark

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