set job control params in job creation POST

[Guy Rixon]

+1

Perhaps we should say that a explicit list of parameters, including  
TERMINATION and the other UWS sub-resources, always have UWS  
semantics in a job-creation post. Then authors of higher-level  
standards know all the possible clashes.

I don't think it needs a special registration flag. I'd expect the  
higher-level standards always to allow the UWS parameters in the POST  
and always to allow certain other parameters on a per-standard basis.  
(If a standard requires a document to be posted will the  
implementation also read parameters in the query string of the URL?  
Consistently?)

This is not impure REST. HTTP-POST is "...used to request that the  
origin server accept the entity enclosed in the request as a new  
subordinate of the resource identified by the Request- 
URI..." [RFC2616] It doesn't say that it has to be an immediate  
child; grandchildren are OK. In fact this is more RESTful than most  
uses of POST.

Cheers,
Guy

On 6 Mar 2009, at 11:07, Paul Harrison wrote:

>
> 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/grid/attachments/20090306/ad10dfea/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2104 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/grid/attachments/20090306/ad10dfea/attachment-0003.bin>