From msdemlei at ari.uni-heidelberg.de  Mon Jul  7 09:09:48 2025
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Mon, 7 Jul 2025 09:09:48 +0200
Subject: TAPRegExt: sync/async preference
Message-ID: <20250707070948.774krioxdrsfvws6@victor>

Dear DAL, Dear Registry,

Let me bring a recent pyVO bug to your attention; there are various
ways to resolve it, and I'd appreciate opinions on what way to go.

Basically, Rubin would like to be able to tell TAP clients: "Prefer
async mode on this service".  I can totally see how, say, TOPCAT,
could pre-set the Mode combo box based on that, and that's enough to
convince me it's a sensible feature.

But of course there are many ways to let a service communicate such a
preference.  See https://github.com/astropy/pyvo/issues/685 for
some discussion and deliberations.

The two approaches I'd currently consider the most plausible would
be:

(small) Just add a <preferredMode> element to the schema.  Rubin
would thus say

  <capability standardID="ivo://ivoa.net/std/tap">
    ...
    <preferredMode>async></preferredMode>

(large) Add a <limits> container element that would contain all the
various limits (executionDuration, outputLimit,...).  This would have
an attribute @mode (say; there are probably better names) that would
say something like sync-auth for "these limits apply to authenticated
users querying synchronously".  You could also express your modal
preference in an attribute to these containers.  So, you could
perhaps say:

  <limits mode="sync-open">
    <executionDuration>
      <default>10</default>
    </executionDuration>
    <outputLimit>
      <default>1000</default>
      <hard>20000</hard>
    </outputLimit>
  </limits>

  <limits mode="async-open" prefer="True">
    <executionDuration>
      <default>10000</default>
    </executionDuration>
    <outputLimit>
      <default>100000</default>
      <hard>20000000</hard>
    </outputLimit>
  </limits>


Discussion
----------

The (small) option has the charm of being doable in a couple of
minutes of spec work and less than an hour on the server side, tests
an all.  I also believe that it will address the problem the Rubin
folks have pretty much exactly and minimally.  I have a hard time
resisting the temptation of "minimal".

On the other hand, we've had the problem of how services express the
*fact* that their limits are very different on their async and sync
endpoints (and probably between auth and non-auth) for a long time.
For instance, my DaCHS instance times you out on sync after 10
seconds, whereas you can have up to 172800 seconds on async.
Current TAPRegExt has no way to communicate that <cough> 3.2 dex
effect to clients, while to me that seems a fairly relevant thing to
say.

On the other hand, the limit element is a bit of work to specify and
quite a bit of additional work to implement.  It is also a bit ugly
in that for backwards compatibility, we will certainly have to keep
around the "default" limits for a while; but then saying "the default
limits are the ones for sync" (or for the preferred mode?) would, I
think, be a reasonable answer for that qualm.

Since (large) solves another, possibly even more important problem
than the Rubin itch, too, I think that *would* be the way I'd prefer.
Except, before I put more work into it, I'd need encouraging words
("rough consensus") and in particular non-binding commitments to put
it into pyVO and (at least inofficially) into TOPCAT, where the
limits displays would then change (sensibly, i.e., probably not
clobbering user inputs) according to the mode switch.  I'd commit to
do the spec work and a server-side implementation in DaCHS.

So... Opinions?  (large) or (small)?  Or yet something else, like my
old dream of RDF-in-VOResource that I mention in in bug #685?

Thanks,

           Markus