TAP Implementation issues (cont'd): UWS

[Guy Rixon]

Tom,

if you want to get the job list then go ahead and do HTTP-GET. That's  
part of UWS (although implementations may restrict the set of you  
reported to be those owned by the caller). What you can't do is use  
HTTP-GET to submit a query via UWS. If you want to use GET to do a  
query then you're doing a synchronous query by definition.

Cheers,
Guy

On 2 Nov 2009, at 14:13, Tom McGlynn wrote:

> Paul Harrison wrote:
>> Guy has already done a good job of answering most of these points - I
>> The UWS design of the two stage process is for two principal reasons
>> a) to be able to manipulate job metadata parameters before the job is
>> run - e.g. the DestructionTime - and receive the feedback from the
>> service whether it is prepared to honour such requests before  
>> actually
>> committing the job.
>> b) to allow complete parameter namespace freedom on the job creation
>> step - i.e. if PHASE is used by UWS then it could not be a parameter
>> for the implementation protocol.
>> So if for a particular implementation using UWS there is no problem
>> with meeting that second condition, then there is no particular  
>> reason
>> why job metadata parameters could not be included with the initial  
>> UWS
>> job creation step if desired - this would require revision of the UWS
>> specification to include this possibility - I think that this is a
>> small enough change to be added into the document as part of the  
>> RFC -
>> it does have a larger impact on possible service implementers however
>> - their code might not be structured to allow this change easily. For
>> a generalized UWS client the change would not be so great, all that
>> would happen is that after the initial submission a job object would
>> be returned with the PHASE=EXECUTING, and general clients should not
>> make any assumptions about state in their coding, so should probably
>> still be able to react appropriately.
>> Just as a side note to show that UWS is not so strange in this
>> multiple interaction between client and server - consider what  
>> happens
>> when a web browser loads a web page - it does the initial get of the
>> html, then parses this html and then gets images, javascript etc.
>> before the page is shown to the user.
>
> I trust the goal is not to require that UWS services need to have  
> the complexity of an interactive visual Web browser.  The protocol  
> should cater to simple applications as well.
>
> I'd be perfectly happy with a change that made it clear that the  
> request that created the job could return it in any state.  In fact,  
> even without the desire to be able to start jobs at creation, that  
> is probably needed to accommodate the situation where there is a  
> problem detected in creating the job but we want the user to be able  
> to parse the error with IVOA protocol level error handling.
>
> The specific text that I find problematic is in 2.1.3:
>
>  PENDING: the job is accepted by the service but not yet committed  
> for execution by the client.  In this state the job quote can be  
> read and evaluated.  This is the state into which a job enters when  
> it is first created.
>
> in conjunction with
>
> 2.2.3.1 Creating a job.
>
> Posting a request to the job list creates a new job (unless the  
> service rejects the request).
>
>
>
> I would suggest something like the following changes
> -
> In 2.1.3 add somewhere
>
>   Phases are ordered with PENDING before QUEUED, QUEUED before  
> EXECUTING and EXECUTING before the trio of COMPLETED, ABORTED and  
> ERROR.  The state of a job may change only to a later state but need  
> not pass through any intermediate state.  A job may be created in  
> any state.
> -
> Delete the last sentence in the definition of PENDING.
> -
>
>
> I think it would be desirable to suggest how a job could be created  
> in the run state even if this is not required by the standard  It  
> would be possible to do this without polluting the parameter name  
> space by specifying a new URI for that.  E.g., ${jobs} creates a new  
> request but does not start it.  ${jobs}/run could create and start  
> the job if that is permitted in the given service.  However I find  
> the worry about pollution of the parameter name space less than  
> compelling, since we require certain parameters to be used in calls  
> to start the job running or to alter other aspects of the job.  It  
> would be poor practice to have phase= mean one thing in a job  
> creation request and mean something else in a job update request.   
> In effect, these parameters are reserved already.
>
>
> This discussion brought up another thing that's not really clear.  
> 2.2.3.1 has the little parenthetical phrase "(unless the service  
> rejects the request)" which is neither explained, nor is the action  
> implied in rejection specified.  I think something like:
>
>   Errors may occur in the creation of the job.  Where possible a job  
> should be created in the ERROR phase with a error message that  
> describes the problems.  If this is not possible, an HTTP 500 error  
> must be returned.
>
> would be clearer for implementation and should replace that phrase.
>
>
> Finally,  one new issue/concern.  [This probably reflects a lack of  
> understanding on my part but if so then perhaps it could be  
> clarified in the standard.]:  It doesn't seem like there is any  
> valid way to get the current job list.
>
> I can't do a GET request for  /{$jobs} because that's cacheable and  
> the list is dynamic.  And I can't do a POST request for it since a  
> post to /{$jobs} means that I'm creating a new job and I'm supposed  
> to be redirected to the job information for the newly created job.
>
> So how do I get to it?
>
> In my TAP implementation I assume that any request to create a new  
> job needs to have a REQUEST= parameter and if I don't see this I  
> return the job list.  If I do, I create the new job.  However this  
> doesn't seem to be literally correct.  I suppose you could say that  
> I'm 'rejecting' the request and since that behavior is undefined I  
> can do anything I want. Relying on undefined behavior doesn't seem  
> satisfactory.
>
> 	Tom
>
>