Running TAP/async jobs immediately: Proposal Text

[Brian Major]

Hi Walter,

On Thu, Sep 29, 2016 at 9:34 AM, Walter Landry <wlandry at caltech.edu> wrote:

> Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:
> > Adjusting UWS to get off the fence about this would also be
> > a possibility (though given that UWS is not up for change right
> > now, not such a grat idea).
>
> I am confused.  At
>
>   http://www.ivoa.net/documents/UWS/
>
> the document is marked as a "Proposed Recommendation made available
> for public review".  The standards process is still not entirely clear
> to me, but I thought that meant it is up for change right now.
>

No, sorry--comments on version 1.1 of UWS are closed now as the proposed
recommendation is only pending approval by exec before it becomes a
recommendation.  More changes will have to wait for 1.2 or 2.0, whichever
is next.


>
> > But, it's a change to the current standard, which is always slightly
> > painful.  And to argue for it on the grounds of N vs N+1 (N>=3)
> > connections seems a bit disingenuous, since if you want a quick in,
> > quick out job you will probably be using the sync endpoint.
>
> I was thinking of jobs that will usually be fast, but might take
> arbitrarily long.  For example, interfaces that allow users to enter
> arbitrary SQL.  For what it is worth, looking around at existing user
> friendly interfaces for async jobs (Gaia, TAPHandle, TOPCAT), it seems
> that submitting a jobs always runs it immediately.
>

My thoughts on the issue:  As long as TAP doesn't explicitly forbid the job
auto-start feature, and if you don't need other TAP services to support it,
I think you can implement it and take advantage of it while remaining
conformant to TAP and UWS standards.


> Cheers,
> Walter Landry
>

Cheers,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160929/27b08122/attachment.html>