From msdemlei at ari.uni-heidelberg.de Mon Sep 15 10:08:20 2025 From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner) Date: Mon, 15 Sep 2025 10:08:20 +0200 Subject: TAPRegExt PR: per-mode limits Message-ID: <20250915080820.uyxd5j2be4bbnzyh@victor> Dear DAL, dear Apps, In pyVO bug #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, , 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. 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? 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 From gregory.mantelet at astro.unistra.fr Mon Sep 15 11:03:02 2025 From: gregory.mantelet at astro.unistra.fr (Gregory MANTELET) Date: Mon, 15 Sep 2025 11:03:02 +0200 Subject: TAPRegExt PR: per-mode limits In-Reply-To: <20250915080820.uyxd5j2be4bbnzyh@victor> References: <20250915080820.uyxd5j2be4bbnzyh@victor> Message-ID: Dear Markus, DAL and Apps, On 15/09/2025 10:08, Markus Demleitner via dal wrote: > Dear DAL, dear Apps, > > In pyVO bug #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, , 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 >