TAPRegExt PR: per-mode limits

[Stelios Voutsinas]

Dear Markus, Gregory, DAL & Apps,


Firstly thank you for the much welcomed work on adding limits to TAPRegExt.

Regarding your question on allowing services to specify a preferred execution mode, I'm on the side (may be a lonely side!) of believe this would be a useful addition.

The primary benefit I see is improved user experience through better client/service interaction for services which are genuinely optimized for async execution (e.g. result size limits, execution durations).

Currently many tools (Topcat, pyvo, etc.) default to sync mode, so for users of async-optimized services this can potentially add a bit of friction to their experience.
It is true that users can override these defaults,  but how this is done isn't always obvious and some users may not be aware of sync & async.

This can lead to confusion when queries fail due to sync limitations, or require additional manual steps each time they interact with the service.  Even experienced users who understand the modes need to remember to specify their preference repeatedly.

A <preferredMode> element would address this by allowing services to communicate their optimization to clients. The preference as I see it would be advisory rather than prescriptive so clients could choose to honor the preference, ignore it entirely or make it configurable.
The preference wouldn't override explicit user choices but would be used just to inform default behavior (e.g., what search() does in pyvo).

That said, I don't view this as critical functionality, as services can already guide users toward appropriate execution modes through documentation or error messages.
But I do think that having this capability would be a plus and improve the out-of-the-box experience for users interacting with services that have clear mode preferences based on their operational characteristics.


Cheers,

Stelios


________________________________
From: dal <dal-bounces at ivoa.net> on behalf of Gregory MANTELET via dal <dal at ivoa.net>
Sent: Monday, September 15, 2025 2:03:02 AM
To: dal at ivoa.net; apps at ivoa.net
Subject: Re: TAPRegExt PR: per-mode limits

Dear Markus, DAL and Apps,


On 15/09/2025 10:08, Markus Demleitner via dal wrote:
> Dear DAL, dear Apps,
>
> In pyVO bug #685 <https://github.com/astropy/pyvo/issues/685>, we
> figured it's finally time to be a bit less cavalier about the limits
> that TAP services report to their clients (e.g., how long can you
> take?  How large can your uploads be? etc).
>
> In TAPRegExt PR #8, <https://github.com/ivoa-std/TAPRegExt/pull/8>, I
> am proposing such a mechanism.  I'd be grateful for a review, both
> technically and content-wise.
>
> As to the latter, I am now convinced that the per-mode limits are
> necessary.  But one might speculate whether we should allow even more
> per-mode variation: Should we allow UDFs to only become available in
> certain modes?  Or perhaps upload formats?  My current take is: no.
> But if these were use cases, perhaps we need a different
> architecture.


I'd say no too. Unless a use case demonstrates this need, I would not
complicate too much the usage of TAP by making async and sync that
much different.


> Also, the starting point of the discussion was whether services
> should be allowed to say: "Please prefer async on this service" or
> so.  That's not yet part of this proposal, mainly because Mark was
> not convinced that's a useful thing to have.  Does anyone disagree?


I join Mark's point of view here by being not convinced about this
possibility.

The way to access and interact with each mode/endpoint is clearly
different. For me, it should be a choice of the user depending on the
needs and preference. Also, this choice could generally be hidden by the
used TAP client (if one is used which is not always the case). One may
prefer to run all queries using the async mode by default, as it allows
longer execution times and some kind of history (thanks to the jobs list).
On the other hand, the sync mode is interesting for a simple usage
(through cURL or so) or to query very quickly a database through a Web
page.

Depending on whether you are on server or client side, the preferred mode
does not have the same meaning. The server will generally have
performance or resource reason to prefer one mode or another. A client
may prefer to use only one mode for simplicity (only one mode to
technically support) or another mode because it would allow more features.
And a user, depending on how he/she needs to query the service may
prefer a mode instead on the other ; and it might change from one day to
another in function of the data to get or anything else. For all these
reasons, I am not in favor of encouraging a particular mode.

Here is my point of view (for the moment).

Cheers,
Grégory


> And then there is the question whether the modes should be enumerated
> in the schema (and thus are more or less fixed) or whether more or
> other modes are conceivable (or useful).
>
> Well: Any contributions are welcome.
>
> Thanks,
>
>            Markus
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20250924/981485f1/attachment.htm>