set job control params in job creation POST

[Paul Harrison]

On 2009-03 -05, at 17:49, Patrick Dowler wrote:

>
> context: In TAP we want to define a TERMINATION parameter for sync  
> queries
> with exactly the same semantics as it has in UWS for async queries.
>
> One thing I discussed with Paul and Guy last summer was whether or  
> not UWS
> allowed one to init/set/request some of the resources in the initial  
> POST
> that creates the job. I recall (could be wrong) the conclusion was  
> that you
> COULD do this for service specific parameters but you COULD NOT do  
> it for UWS
> concepts and had to address job control POSTs to the specific child  
> web
> resource. That would mean that in TAP something like
>
> POST /sync?TERMINATION=600&...
>
> is allowed while
>
> POST /async?TERMINATION=600
>
> is not. There are many examples in the TAP doc where other TAP- 
> specific
> parameters are POSTed in the job creation step. This was thought to  
> be OK but
> it leaves an odd disconnect (especially for users) since some params  
> can be
> set at job creation and some (UWS defined) cannot. The situation  
> will be
> worse if the rules are different for the /async and /sync endpoints.

As you remember, I was not in favour of trying to set the job control  
parameters in the initial POST because of the possible clash of a  
control parameter name with a job parameter name in the general UWS  
case - however, I am more relaxed  about a specific implementation of  
UWS, where the clash is known not to occur - so for TAP It would be  
OK, but for CEA it would not (because CEA is a sort of meta protocol  
and the parameter names are "chosen" by the particular installation  
and are dependent on the application being wrapped).

In the general case there is a way out here with making a distinction  
between parameters that are specified in the body of the post (job  
parameters) and those in the URL (job control parameters) - however I  
do not think that this helps too much in the TAP case where the PARAM  
version of the query appears in the URL string so that there is mixing  
anyway.
>
>
> The goal (in TAP, but it is a general issue) is that we want to be  
> able to run
> synchronously or asynchronously by just changing the endpoint. To  
> fully
> accomplish that, one has to at least be permitted to completely  
> specify the
> job in a single POST - e.g. the job creation POST in the case of  
> async. This
> is simple enough to implement.
>
> Has this been addressed in UWS 0.5? Thought about further?
>

My feeling on this not to be too much of a REST purist and alter the  
UWS specification should say that it is allowable to set job control  
parameters in the initial post if the particular implementation has no  
issues with possible name clashes - i.e. the specification of the  
implementation should say whether this is allowed - it might also be  
necessary for some registration flag be used to indicate this  
possibility to aid generalized UWS clients. Note that all  
implementations should also allow the full REST style setting of job  
control parameters.

Paul.

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