TAPRegExt: sync/async preference

[Grégory Mantelet]

Thank you Paul for this suggestion. I just commented on the original idea.

Anyway, with the suggestion you've proposed, it means that a service able to
provide such advanced/smart sync response would have to:

- either always run the query asynchronously
   (even though the sync layer said it timed out, it would keep running 
in the
    potential hope someone may click on the "wait for the response" link and
    switch on the async endpoint)

- or will have to restart the query if the user click on the "wait for 
the response"
   link

Maybe there is another technical server solution. If not, any of these 
solutions
convince me that this server complexity worth the effort. Let's keep things
simple.

I still think that such behavior should be applied on client side. And 
that would
be even more possible thanks to what Stelios has just proposed with a
standardized error type in DALI answers. If a sync query fails with a 
time out
error, the client can propose to try again in async mode. Then, as I 
said, a client
may also decide to run everything on async mode and show immediately
the result if it succeeded quickly (as TAPHandle does).

Cheers,
Grégory


On 15/07/2025 18:22, Paul Harrison wrote:
>
>
>> On 15 Jul 2025, at 14:41, Gregory MANTELET via dal <dal at ivoa.net> wrote:
>>
>>
>> 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
>
> What I suggested is a backwards compatible extension for “dumb" 
> clients assuming that they always treat a non-2xx http response is an 
> error. It is still a sync endpoint that can time-out (which could 
> happen in the current UWS/TAP standard definitions) - it is just that 
> the timeout *could* contain information that would allow a slightly 
> less dumb client to see that it might be possible still to obtain the 
> result if they are prepared to wait longer and do the full async 
> protocol. Simple clients do not have to do any more work than before.
>
> Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20250717/24e89465/attachment.htm>