TAP Implementation issues (cont'd): UWS

[Tom McGlynn]

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