<div dir="ltr">Hi Grid,<div><br></div><div>(Dropped registry, dal from this thread)</div><div><br></div><div>I thought I'd offer my opinion on the support of synchronous job running in UWS...</div><div><br></div><div><div class="gmail_quote"><div dir="ltr">On Mon, Jun 11, 2018 at 3:14 PM Mark Taylor <<a href="mailto:m.b.taylor@bristol.ac.uk">m.b.taylor@bristol.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My feeling is that if you're going to use sync mode, it's because<br>
you don't want to muck about with all that job ID business.<br>
I always thought of UWS as a protocol for clients that want job metadata<br>
(either to support long-running jobs or for other reasons)<br>
and synchronous services as for clients that don't.<br></blockquote><div><br></div><div>Yes, that's a good point. The UWS 1.1 spec does provide a suggested (informative) recipe for implementing a sync endpoint. If a service were written with that recipe then clients could indeed ignore all the jobID business by simply choosing to follow all redirects on the initial job request.</div><div><br></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> <a href="http://ivoa.net/documents/UWS/20161024/REC-UWS-1.1-20161024.html#SynchronousService">http://ivoa.net/documents/UWS/20161024/REC-UWS-1.1-20161024.html#SynchronousService</a><br></span></div><div><br>I think it is often in the hands of the user as to whether a job should be run synchronously or asynchronously. They would prefer an immediate result so would favour synchronous but would understand that for some tasks asynchronous would be better (error handling, timeouts, lots of output, etc...) . For these types of services where the need for asynchronous execution is required, you may want to offer a similar experience for clients to potentially run the same things synchronously. That is, the same way of gathering the task parameters and the same way of getting at results. So, I think there's a case to be made that, if a there is a need for async support and a desire to offer sync for convenience, they should be be offered in a similar manner.</div><div><br></div><div>(Looking at it another way: would there ever be value in writing a sync-only service using the UWS pattern? I would argue probably yes.)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But at least I would be wary of, e.g., requiring something like<br>
a TAP sync endpoint to be marked up in such a way that it has<br>
to be implemented in a UWS-like way, rather than just delivering<br>
the result and forgetting about it. I know some services do<br>
implement sync on top of async so that would not be an implementation<br>
issue, but others may not.<br></blockquote><div><br></div><div>Yes, I think official UWS sync support would have to be the same as simply delivering the results. (Maybe with the condition that clients must choose to follow all redirects.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I am not violently opposed to using UWS as a place to to hang<br>
these sync/async markers, but I still find it a bit unintuitive<br>
to have UWS talking about synchronous services.<br></blockquote><div><br></div><div>I can understand this point but I also think that since it is the same work being executed (with sync or async) we may as well make them as similar as possible in the other ways for clients.</div><div><br></div><div>More below...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Mark<br>
<br>
On Wed, 30 May 2018, Patrick Dowler wrote:<br>
<br>
> The home for these concepts depend on a couple of predictions we might<br>
> make:<br>
> <br>
> 1. Is it useful for UWS to be extended to specify interface behaviour for<br>
> synchronous job execution? TAP, SODA, and VOSpace all have "jobs" that can<br>
> run in either mode and s/w choses the endpoint with the behaviour it<br>
> wants... the minimal "specification" of UWS-sync would be a standard way<br>
> for a client executing a sync job to get the jobID and access it via a<br>
> joblist (eg in UWS-next)<br></blockquote><div><br>As per above, my feeling is that there is a benefit to UWS offering sync support.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> 2. Ae there common metadata about the UWS job endpoint that could be<br>
> conveyed by adding content to the UWSRegExt? e.g. will UWSRegExt go beyond<br>
> providing tagging interface in future? This one I am less sure about.<br>
> TAPRegExt already describes some of the UWS job control limits, for<br>
> example, but that reg-ext defines a new capability type (the type of<br>
> job)... I do have some UWS-defined features that are interface-specific so<br>
> there are use cases.<br></blockquote><div><br>I know that there are a couple of UWS client software tools out there but I haven't taken a close look at them. I am wondering if these tools can be used (without plugins or customization) to speak to UWS services such as TAP and SODA independently. If so, then I imagine it puts a lot of responsibility in the hands of the user to formulate the correct input for the different services. Perhaps this is an area where extended UWS metadata could help...<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> I do think it is important for us, as a community, to find ways to do small<br>
> things and get them done in a short time, and then iterate more rapidly on<br>
> minor versions.<br></blockquote><div><br>+1 on that.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> my 2c,<br>
> <br>
> Pat<br></blockquote><div><br></div><div>Cheers,</div><div>Brian</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> On 29 May 2018 at 17:21, Brian Major <<a href="mailto:major.brian@gmail.com" target="_blank">major.brian@gmail.com</a>> wrote:<br>
> <br>
> > Hi DAL, Registry and Grid,<br>
> ><br>
> > Sorry for the wide distribution but this touches all three working groups.<br>
> ><br>
> > An initial note for the UWS Registry Extension has been written and can be<br>
> > viewed here:<br>
> ><br>
> > <a href="http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/" rel="noreferrer" target="_blank">http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/</a><br>
> > UWSRegExt.pdf<br>
> ><br>
> > It is very simple: the essence of the note is to allow registry interface<br>
> > entries to 'tag' interfaces as being UWS synchronous or asynchronous<br>
> > endpoints. This is to allow implementers of UWS services (TAP is the<br>
> > working example) the freedom of having separate URLs for interfaces with<br>
> > various security methods (supported authentication) and to have custom URLs<br>
> > for sync and async endpoints.<br>
> ><br>
> > Comments are welcome. There is still uncertainty about how the<br>
> > information in this note should be brought in as a document for reference<br>
> > by TAP 1.1, so comments on that are welcome too.<br>
> ><br>
> > Brian<br>
> ><br>
> ><br>
> > On Thu, Feb 22, 2018 at 4:58 PM Brian Major <<a href="mailto:major.brian@gmail.com" target="_blank">major.brian@gmail.com</a>> wrote:<br>
> ><br>
> >> Hi Grid, Registry,<br>
> >><br>
> >> At the Santiago Interop we decided to identify the sync and async<br>
> >> endpoints of a TAP 1.1 capability by setting the 'type' of the Interface<br>
> >> element as one of either<br>
> >><br>
> >> uws:Sync or<br>
> >> uws:Async<br>
> >><br>
> >> instead directly in the standardID of the capability like<br>
> >><br>
> >> ivo://<a href="http://ivoa.net/std/tap#sync-1.1" rel="noreferrer" target="_blank">ivoa.net/std/tap#sync-1.1</a> and<br>
> >> ivo://<a href="http://ivoa.net/std/tap#async-1.1" rel="noreferrer" target="_blank">ivoa.net/std/tap#async-1.1</a><br>
> >><br>
> >> We have implemented this in our TAP (1.1) services using the XSD here:<br>
> >><br>
> >> <a href="https://github.com/opencadc/reg/blob/master/cadc-registry/" rel="noreferrer" target="_blank">https://github.com/opencadc/reg/blob/master/cadc-registry/</a><br>
> >> src/main/resources/UWSRegExt-v0.1.xsd<br>
> >><br>
> >> And it is all working as expected, no issues.<br>
> >><br>
> >> Now I am wondering now where this XSD can be placed within the IVOA and<br>
> >> how it can be documented to describe the intended use. This will need to<br>
> >> go somewhere official ahead of TAP 1.1. Any suggestions are welcome.<br>
> >><br>
> >> Thanks,<br>
> >> Brian<br>
> >><br>
> >><br>
> >><br>
> >><br>
> <br>
> <br>
> -- <br>
> Patrick Dowler<br>
> Canadian Astronomy Data Centre<br>
> Victoria, BC, Canada<br>
> <br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a> +44-117-9288776 <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
</blockquote></div></div></div>