<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi Pat, Mark, Paul, Markus,<br>
<br>
To be honest, I don't like either this false-<i>sync</i> endpoint.
Changing that way<br>
the behavior of this endpoint is clearly a breaking change. I expect
a lot<br>
of clients that may be broken by such a change. Besides, as Mark
said, this<br>
endpoint is really convenient for quick queries run by simple
scripts: the<br>
<i>sync</i> API is very simple and easy to use. Thus, a sync request
is easy to<br>
design (especially for malicious intent) and to run. If we change
it, firstly,<br>
there is no more point to name it <i>sync</i> (and for this
endpoint to exist<br>
anyway), and secondly, it breaks the behavior expected by the user.
It is<br>
quite like creating a simple function named <i>doSomethingWithSimpleAPI()</i><br>
which actually does <i>doSomethingWithADifferentAndMoreComplexAPI()</i>.<br>
After this, the user may not really trust completely the TAP API and
I would<br>
not blame him/her.<br>
<br>
However, such behavior is fine for a TAP client. If a TAP client
hides the<br>
execution mode by running everything in <i>async</i> mode, it is OK
for my point<br>
of view (probably a subjective point of view here as we are actually
working<br>
on a TAP web interface which will do this). This is fine because it
is a client<br>
choice which will not impact any other way to query the same
service.<br>
<br>
Having both execution modes is, according to me, a nice thing to
have,<br>
considering the complexity of UWS and ADQL. Users that want to run a<br>
simple and quick query can do that with a simple API, otherwise,
they know<br>
that they will have to put more efforts by adding a UWS layer. This
is their<br>
choice.<br>
<br>
Now, to come back on the Markus' question, I'd be in favor of
(large), for<br>
the same reasons as you, Markus: 2 use-cases covered by this
solution.<br>
But I have to say that I have some concerns about what happens when<br>
no <i>mode</i> attribute is provided (like for older TAP services).
In such situation,<br>
I'd say that it applies to both modes (like a global definition)
unless any<br>
specific one is specified just after (like a variable overwrite).
But for sure,<br>
it is more work, especially for TAP clients.<br>
<br>
Cheers,<br>
Grégory<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/07/2025 11:56, Mark Taylor via
dal wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9e7ddbc2-196f-f491-f83f-394f7621b439@andromeda.star.bris.ac.uk">
<pre class="moz-quote-pre" wrap="">On Wed, 9 Jul 2025, Patrick Dowler via dal wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:m.b.taylor@bristol.ac.uk">m.b.taylor@bristol.ac.uk</a> <a class="moz-txt-link-freetext" href="https://www.star.bristol.ac.uk/mbt/">https://www.star.bristol.ac.uk/mbt/</a>
</pre>
</blockquote>
<br>
</body>
</html>