UWS 1.1 working draft

[Mark Taylor]

On Wed, 4 Jun 2014, Patrick Dowler wrote:

> On 03/06/14 11:58 PM, Paul Harrison wrote:
> > I think that we could avoid the race conditions that Mark is worried about
> > with some explicit rule on the server that it never blocks for one of the
> > terminal phases (as Pat said below). Additionally saying that the server
> > must return always when phase changes (but can return sooner) should address
> > Mark’s concerns I think.
> 
> Yes, that is the whole intent of never blocking once the job reaches a
> terminal phase: avoid getting stuck due to a race condition. It is a critical
> feature of the general blocking behaviour... I was thinking about it in the
> sense of "waitForTrue" when using a mutex in multi-threaded programming...
> where "true" in this case is somewhat vague and implementation specific.
> 
> > It seems to me a pretty sensible suggestion to make this full blocking
> > generalisation  - my only concern is really that we might be missing
> > something that does not allow this to be a “1.1” release - i.e. breaks
> > backward compatibility. If no-one comes up with any objections I will make
> > the changes to the WD.
> 
> It seems that a new child resource would give a 404 (not found) until a
> service is "upgraded" to UWS 1.1 no matter what that resource was. If the new
> resource was optional (and 404 was the correct response when not supported)
> then all existing services would comply by default to UWS-1.1; I looked at 501
> (not implemented) but it appears to be intended for HTTP request methods
> rather than generic lack of functionality... so 404 is probably the right
> RESTful thing anyway.
> 
> Having said that, I'm not crazy about optional things, especially those that
> are admittedly tricky to implement, as support may not be widely available.
> And I don't know that there is any way to describe your service such that you
> convey which version of UWS you support as it is always secondary to the
> actual standardID of the capability.

Optional things are not problematic from the point of service developers,
the downside is at the client end.  As a client writer, I'd still like
to see this as an optional feature; the benefit of using it would be
sufficient that I'd envisage writing code to try the blocking endpoint
first, and fall back to the old behaviour if not.  I don't think the
fact that the presence/absence of such a capability is not advertised
is a much of a problem here.  Just my 2c.

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/