[DALI] posting parameters to a DAI-async (aka UWS) job

[Patrick Dowler]

I think it could make sense to copy an existing job's JDL when creating 
anew job, but that we should leave out of DALI and wait for UWS-1.1; in 
DAL we will likely have to be able to specify (in the capabilities) 
which rev of UWS a resource uses so we can start using new features 
without issuing new DAL specs. Ive tried to do that with VOSI (allow for 
future versions to be used) in the text of the document.

So, it looks like everyone (Mark, Pierre's link, Markus, Paul, and me - 
wow!) agrees that POST to /joblist/jobid with DAL params is an 
unnecessary and bad thing and even though UWS-1.0 allows it DALI could 
ban it. That might force UWS-1.x to also ban it so by the time TCG 
review comes up the GWS-WG will need to formulate a position. (eg we can 
argue and discuss that in GWS at the interop :-)

Decided: DALI will ban posting DAL parameters to the job.

I will also clarify that implementers can implement future UWS semantics 
so that if we ant to add support for POST/PUT/DELETE of params in the 
/parameters list we can add that to UWS-1.x and DAL services can use it.

Thanks all,

Pat


On 04/26/2013 03:06 AM, Paul Harrison wrote:
> I think that there might be another use-case for this - as I wrote below, but I see that I had mangled my first sentence...
>
> Basically it might allow for a quick way to rerun a job with a tweaked parameter - if there were also an easy way to copy a job instance.
>
> btw - multi valued parameters could already be specified in the initial post by just repeating the parameter/value pair for instance
>
>
> On 2013-04 -26, at 10:36, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
>
>> I'm all in favour of banning posting params to an existing job.
>>
>> Posting to /parameters adding more instances: are you suggesting
>> the possibility of PUT to overwrite the param as well (and DELETE?)?
>> If not, this seems like the capability to do just one rather specialised
>> thing (add items to a multiple-valued parameter) to the parameters
>> following job creation, while other ways of changing it are not
>> available.  I've got no strong objection, but it doesn't seem
>> like a particularly well-motivated capability.
>>
>
>
>
> On 2013-04 -26, at 08:51, Paul Harrison <paul.harrison at manchester.ac.uk> wrote:
>
>> My other thought that is related to a use that might be made of being a this facility to change individual parameters of a job - one typical one is to be able to re-run a job with just one parameter slightly tweaked.
>>
>> It would be convenient for the client if there were a way of getting a representation of the existing job that could be simply POSTed back to re-run it if necessary - the current XML representation of the job state requires the client to do work to transform that into a form that can be resubmitted - perhaps there could be an option to return a suitably encoded form of the job parameters that could be simply rePOSTed to create a new job?
>>
>> The other alternative to this is that there is an explicit way to copy a job on the DALI/UWS server, so that there is a new copy of a job put into the pending state which can then have a parameter tweaked before being executed - I suspect that this would be a relatively easy operation for most servers to implement, and would be very convenient for clients (as well as allowing the possibility of saving bandwidth  re-uploading large parameter values).
>>
>
>
>
> .
>

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9A 2L9

250-363-0044 (office) 250-363-0045 (fax)