Running TAP/async jobs immediately: Proposal Text

[Walter Landry]

Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> If people are doing quick queries that respond immediately and they
> want to minimise connection overhead... TAP-sync? That's what it is
> for. With TAP-async you have to stage the results someplace, which
> adds way more latency than an extra connection... so, use TAP-sync!

TAP-sync is not appropriate for queries which might have unbounded
execution time.  Also, staging happens at the archive in server farms.
Connections happen over the internet over spotty wifi.  The result does
not even have to be physically written to disk before the user fetches
it.  So I can easily see places where staging is much faster than
making connections.

Moreover, an optimistic user can get by with only 2 connections
(submit + fetch), because they can tell if they get back a 404 or
incomplete result.  We should not be making our protocols needlessly
slower.

> While TAP-async could mandate support for this, we cannot remove
> support for the multi-request UWS way (so you need that too) and thus
> we can't mandate clients use this... which means Brian is right: you
> can do this and your own client/portal can take advantage of it with
> no spec change.

Mandating support for single-request means that people can rely on it.
It makes TAP-async faster and easier to use.  I do not know the details
of everyone's implementation, but I would fall off my chair if this is
actually more work than writing these emails ;)

Cheers,
Walter Landry