TAPRegExt: sync/async preference

[Markus Demleitner]

Hi Pat,

On Wed, Jul 09, 2025 at 10:34:44AM -0700, Patrick Dowler via dal wrote:
> note: specifically in this case, tap_schema queries execute in the
> simple/direct/normal way and queries on the other content are
> performed in async mode.

Hm.  That, of all things, TAP_SCHEMA is the odd one out here (in
addition to the general uglyness of having the same data in two
places and the pain with manipulating TAP_SCHEMA when it "changes"
due to authentication) to me is another indication that we ought to
move towards communicating our table metadata through VOSI
exclusively.

But that's just a ceterum censeo.

> 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"

Since we really want clients to implement async anyway, it would seem
to me that (2) should not complicate things much, and thus it would
be my choice, too.

On (1), there was a bit of discussion in pyVO bug #683
<https://github.com/astropy/pyvo/issues/683> without much of a
convincing outcome; to me, that also suggests looking into (2).

> 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,

At some point I think we have to accept that complex patterns and
simple tools may not always mix well despite our best efforts (to
both keep patterns as simple as possible and to make things
accessible to simple tools whenever reasonable).

        -- Markus