TAPRegExt: sync/async preference

[Gregory MANTELET]

Hi Pat, Mark, Paul, Markus,

To be honest, I don't like either this false-/sync/ endpoint. Changing 
that way
the behavior of this endpoint is clearly a breaking change. I expect a lot
of clients that may be broken by such a change. Besides, as Mark said, this
endpoint is really convenient for quick queries run by simple scripts: the
/sync/ API is very simple and easy to use. Thus, a sync request is easy to
design (especially for malicious intent) and to run. If we change it, 
firstly,
there is no more point to name it /sync/ (and for this endpoint to exist
anyway), and secondly, it breaks the behavior expected by the user. It is
quite like creating a simple function named /doSomethingWithSimpleAPI()/
which actually does /doSomethingWithADifferentAndMoreComplexAPI()/.
After this, the user may not really trust completely the TAP API and I would
not blame him/her.

However, such behavior is fine for a TAP client. If a TAP client hides the
execution mode by running everything in /async/ mode, it is OK for my point
of view (probably a subjective point of view here as we are actually working
on a TAP web interface which will do this). This is fine because it is a 
client
choice which will not impact any other way to query the same service.

Having both execution modes is, according to me, a nice thing to have,
considering the complexity of UWS and ADQL. Users that want to run a
simple and quick query can do that with a simple API, otherwise, they know
that they will have to put more efforts by adding a UWS layer. This is their
choice.

Now, to come back on the Markus' question, I'd be in favor of (large), for
the same reasons as you, Markus: 2 use-cases covered by this solution.
But I have to say that I have some concerns about what happens when
no /mode/ attribute is provided (like for older TAP services). In such 
situation,
I'd say that it applies to both modes (like a global definition) unless any
specific one is specified just after (like a variable overwrite). But 
for sure,
it is more work, especially for TAP clients.

Cheers,
Grégory


On 10/07/2025 11:56, Mark Taylor via dal wrote:
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20250715/1fcb7582/attachment.htm>