[DALI] posting parameters to a DAI-async (aka UWS) job
Paul Harrison
paul.harrison at manchester.ac.uk
Fri Apr 26 00:51:43 PDT 2013
On 2013-04 -25, at 22:40, Patrick Dowler <patrick.dowler at nrc-cnrc.gc.ca> wrote:
>
> SO you would be in support of banning the POST of params to an existing job and only allow them at creation or to the /parameters child resource?
>
> Would you also support DALI mandating the "particular implementation" of UWS you mention below (eg with POST to modify and PUT to add params to the /parameters resource)? Or should we continue with POST to /parameters just adding more (eg potentially multiple) params since DALI does allow for params to have mutiple values...
>
>
> My preference would be to ban posting params to an existing job, and have posting of params to /parameters add more instances to that list.
>
That is what I think would be more sensible - so that only job control messages are sent to /{jobs}/{jobid} and there is no possibility of ambiguity.
> Any other opinions? If not, I will make this change…
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).
Paul.
More information about the dal
mailing list