Possible changes to UWS

[Paul Harrison]

On 2008-05 -20, at 16:08, Guy Rixon wrote:

> Hi,

It is a shame that the session on this is at the end of the week, as  
some of the requested changed will make more sense after a  
demonstration.

>
> Paul Harrison reported (http://www.ivoa.net/internal/IVOA/AsynchronousHome/ImplementingUWS-0.1.pdf 
> ) on a UWS-0.3 implementation and suggested some changes to the UWS  
> pattern. Here are some responses.
>
> Change the way a job is committed for excution to "post to phase  
> resource". I accept the advantage of the client not addressing the  
> quote  object. Would it be better to allow the client to HTTP-put  
> the phase resource? Or HTTP-post with phase=run to the job resource  
> itself?

I chose POST rather than PUT because this is a request to change  
state,  - the service might not be able to respond immediately, so a  
GET straight after might still return the PENDING state - if this were  
PUT you would expect to get the value back that you PUT.

I think that the question of whether to POST to the job object instead  
is an open issue for all of the sub objects. I have no particular  
personal preference for either, but chose POSTing direct to the sub- 
object, as this pattern had been used already, so I followed that.

>
> Extra job state "ABORTED". Yes we could add this. Is there a  
> particular use case that needs it?

Needed because for a job that has been stopped before its destruction  
time it is useful to know exactly how it terminated (as I have  
termination and abortion not implicitly deleting the job)
>
> Distinguish termination time from destruction time. This could work,  
> but is it  really needed? For setting the times, HTTP-put would be  
> preferred.

I think that it is actually a very useful addition to the pattern (and  
in fact the only one that could not  be considered in some way  
cosmetic). It allows you to potentially use the UWS output of one job  
directly as the input to the next job in a workflow, without needing  
to go via vospace.

Termination time could be viewed as a CPU time limit (and as such  
perhaps an absolute real time is not such a good idea - a period of  
CPU seconds be better) - Destruction time could be viewed as a data  
storage time limit.

My justification for using POST is that again this is can only be  
viewed as a request to change the times - the server might have  
policies that prevent you from setting the time exactly as requested.

>
> Error object. I concur. Since the error has its own resource, I  
> guess the service could use an HTML representation if the client  
> accepted such.
>
> Require action=DELETE on job-destruction posts. Accepted; it's a  
> good safeguard.
>
> Composite metadata. I agree with the principle. We need to look very  
> closely at the implementation.
>
> XML and HTML representations. UWS 0.2 did use the stylesheet link to  
> transform in the browser as Paul suggests. I went to the other  
> technique for 0.3 partly to get a comparison and partly to work  
> around some J2EE issues in a quick implementation. I'm happy to go  
> back to client-side transformation for the next draft.
>
> "Reload later" (503) response. I'm not clear when this is to be  
> used. Is it instead of a 404 when an output isn't ready?

yes - I am trying to do this if you ask for a result before it is ready.

>

Dr. Paul Harrison
JBCA, Manchester University
http://www.manchester.ac.uk/jodrellbank



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/grid/attachments/20080521/4a037066/attachment-0001.html>