<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Dear Stelios,<br>
<br>
I perfectly understand your point of view. As an individual user,
either you<br>
prefer to use one specific mode (for whatever reason) or you know
that for<br>
a specific service it is more efficient to directly run a
synchronous query.<br>
<br>
From my point of view, being both user and provider, my preference
changes<br>
in function of the query I have to run. Because, as you say, I am
aware of<br>
the different execution modes. And this, is my personal way to use
the service<br>
as your personal way is to use the async mode by default. Then, I
assume<br>
that other users have a different way to use a TAP service. For
instance, some<br>
may just start with a sync execution, and then go for an async one
if the query<br>
execution times out too quickly. Others would prefer to use the
async mode<br>
combined with authentication to keep some kind of history of their
queries.<br>
Some others would prefer the sync mode to get immediately the result<br>
without going through all the UWS madness ; especially if you run
your query<br>
from command line.<br>
<br>
In brief, there are many use cases and I don't think that forcing a
default<br>
execution mode for all users of a given TAP service is a good
solution to your<br>
problem.<br>
<br>
Actually, I keep thinking that the issue is on the client side.
Clients are<br>
choosing by default the sync mode, but no standard says that sync
should be<br>
the default one. From my point of view, the best solution would be
that<br>
clients let users choose their preferred execution mode, either for
all services<br>
or individually for each one. I am quite sure that can be done
relatively quickly<br>
on the most used clients (e.g. TOPCAT, PyVO), but I let clients
developers<br>
gives their feeling about this, especially if I am wrong.<br>
<br>
Cheers,<br>
Grégory<br>
<br>
<br>
<div class="moz-cite-prefix">On 24/09/2025 20:03, Stelios Voutsinas
via dal wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e3c44acc57c94671bccb0dce7f7eb205@lsst.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text -->
<style>.EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; }</style>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">p
{margin-top:0;
margin-bottom:0}</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr"
style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<div>Dear Markus, Gregory, DAL & Apps,</div>
<div><br>
<br>
</div>
<div>Firstly thank you for the much welcomed work on adding
limits to <span
style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">TAPRegExt.</span></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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). </div>
<div><br>
</div>
<div>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.</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div>The preference wouldn't override explicit user choices
but would be used just to inform default behavior (e.g.,
what search() does in pyvo).</div>
<div><br>
</div>
<div>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. </div>
<div>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.</div>
<div><br>
<br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Stelios</div>
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font
face="Calibri, sans-serif" color="#000000"
style="font-size:11pt"><b>From:</b> dal
<a class="moz-txt-link-rfc2396E" href="mailto:dal-bounces@ivoa.net"><dal-bounces@ivoa.net></a> on behalf of Gregory MANTELET
via dal <a class="moz-txt-link-rfc2396E" href="mailto:dal@ivoa.net"><dal@ivoa.net></a><br>
<b>Sent:</b> Monday, September 15, 2025 2:03:02 AM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:dal@ivoa.net">dal@ivoa.net</a>; <a class="moz-txt-link-abbreviated" href="mailto:apps@ivoa.net">apps@ivoa.net</a><br>
<b>Subject:</b> Re: TAPRegExt PR: per-mode limits</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Dear Markus, DAL and Apps,<br>
<br>
<br>
On 15/09/2025 10:08, Markus Demleitner via dal wrote:<br>
> Dear DAL, dear Apps,<br>
><br>
> In pyVO bug #685 <<a
href="https://github.com/astropy/pyvo/issues/685"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/astropy/pyvo/issues/685</a>>,
we<br>
> figured it's finally time to be a bit less cavalier
about the limits<br>
> that TAP services report to their clients (e.g., how
long can you<br>
> take? How large can your uploads be? etc).<br>
><br>
> In TAPRegExt PR #8, <<a
href="https://github.com/ivoa-std/TAPRegExt/pull/8"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/ivoa-std/TAPRegExt/pull/8</a>>,
I<br>
> am proposing such a mechanism. I'd be grateful for a
review, both<br>
> technically and content-wise.<br>
><br>
> As to the latter, I am now convinced that the per-mode
limits are<br>
> necessary. But one might speculate whether we should
allow even more<br>
> per-mode variation: Should we allow UDFs to only become
available in<br>
> certain modes? Or perhaps upload formats? My current
take is: no.<br>
> But if these were use cases, perhaps we need a
different<br>
> architecture.<br>
<br>
<br>
I'd say no too. Unless a use case demonstrates this need, I
would not<br>
complicate too much the usage of TAP by making async and
sync that<br>
much different.<br>
<br>
<br>
> Also, the starting point of the discussion was whether
services<br>
> should be allowed to say: "Please prefer async on this
service" or<br>
> so. That's not yet part of this proposal, mainly
because Mark was<br>
> not convinced that's a useful thing to have. Does
anyone disagree?<br>
<br>
<br>
I join Mark's point of view here by being not convinced
about this <br>
possibility.<br>
<br>
The way to access and interact with each mode/endpoint is
clearly<br>
different. For me, it should be a choice of the user
depending on the<br>
needs and preference. Also, this choice could generally be
hidden by the<br>
used TAP client (if one is used which is not always the
case). One may<br>
prefer to run all queries using the async mode by default,
as it allows<br>
longer execution times and some kind of history (thanks to
the jobs list).<br>
On the other hand, the sync mode is interesting for a simple
usage<br>
(through cURL or so) or to query very quickly a database
through a Web<br>
page.<br>
<br>
Depending on whether you are on server or client side, the
preferred mode<br>
does not have the same meaning. The server will generally
have<br>
performance or resource reason to prefer one mode or
another. A client<br>
may prefer to use only one mode for simplicity (only one
mode to<br>
technically support) or another mode because it would allow
more features.<br>
And a user, depending on how he/she needs to query the
service may<br>
prefer a mode instead on the other ; and it might change
from one day to<br>
another in function of the data to get or anything else. For
all these<br>
reasons, I am not in favor of encouraging a particular mode.<br>
<br>
Here is my point of view (for the moment).<br>
<br>
Cheers,<br>
Grégory<br>
<br>
<br>
> And then there is the question whether the modes should
be enumerated<br>
> in the schema (and thus are more or less fixed) or
whether more or<br>
> other modes are conceivable (or useful).<br>
><br>
> Well: Any contributions are welcome.<br>
><br>
> Thanks,<br>
><br>
> Markus<br>
><br>
<br>
</div>
</span></font>
</blockquote>
<br>
</body>
</html>