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

Fri Apr 26 02:53:16 PDT 2013

Hi

We have proposed in Naple to simplify this procedure
http://wiki.ivoa.net/internal/IVOA/InterOpMay2011GWS/normand_malapert_lesidaner_uwsIVOA2011V2.pdf
We can propose simple evolution of UWS in Heidelberg

Regards
Pierre

On 04/26/2013 11:36 AM, Mark Taylor 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 Thu, 25 Apr 2013, Patrick Dowler 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.
>>
>> Any other opinions? If not, I will make this change...
>>
>> Pat
>>
>> On 04/25/2013 05:41 AM, Paul Harrison wrote:
>>> On 2013-04 -24, at 17:43, Patrick Dowler <patrick.dowler at nrc-cnrc.gc.ca>
>>> wrote:
>>>
>>>> The PR-DALI and the UWS spec (interpretting the latter liberally) allow
>>>> the caller to POST job parameters in three ways:
>>>>
>>>> 1. included with the initial post to the job list (eg during job
>>>> creation). This is useful and efficient as it allows one to completely
>>>> specify a job in one POST and (for DALI) it makes sync and async that much
>>>> more similar to use. We definitely want this.
>>>>
>>>>
>>>> 2. to the parameters resource (eg /srv/joblist/<jobid>/parameters). This
>>>> is unambiguous: you are modifying that list of parameters.
>>>>
>>>>
>>>> 3. directly to the job url (eg /srv/joblist/<jobid>). This is kind of
>>>> sketchy to implement, especially if one starts thinking about allowing the
>>>> UWS job control params here (and in #1) and then "putting things where
>>>> they belong"...
>>>>
>>>> *** TODO ***
>>>>
>>>> What we can do right now in DALI is restrict what the UWS-1.0 spec allows.
>>>> The suggestion is to completely forbid #3 and only allow #1 and #2.
>>>>
>>>>
>>>> Disclosure: The OpenCADC library (cadcUWS) does make all of these work,
>>>> but while we do use feature #3 I'm willing to make that change as I did
>>>> always consider it overly complex (to implement) and lazy (on the caller
>>>> side).
>>>>
>>>>
>>>> Notes on #2: For this to be really purely RESTful, one should require PUT
>>>> to add a parameter to the list and POST (to
>>>> /srv/joblist/<jobid>/parameters/FOO) would be used to modify an existing
>>>> param. DALI allows multiple instances of a param so the current
>>>> UWS/interpretation does not have a way to distinguish between adding a
>>>> param and modifying one. BUT: I think this is something for a future UWS
>>>> spec.
>>>>
>>>>
>>>
>>> Initially the intention of UWS was that all job parameters were only
>>> specified at job creation - i.e. as #1 above and that the endpoint
>>> /srv/joblist/<jobid> was only to be used to set "job control" parameters
>>> (e.g. execution duration) - nothing was said about the contents of the
>>> initial POST that created the job, and as that was the only way to specify
>>> the functional parameters for a job it was possible for a client to resubmit
>>> a job by simply sending the same POST.
>>>
>>> Then when TAP wanted to use UWS it became clear that UWS ought to support
>>> the notion of the simple name/value parameter pairs that appear in typical
>>> DAL services, so this was added to UWS 1.0, and additionally the ability to
>>> set parameters individually has been added (as in #2) to the latest draft
>>> (1.1) see
>>> (http://volute.googlecode.com/svn/trunk/projects/grid/uws/doc/UWS.html) of
>>> UWS following discussions at the Napoli interop.
>>>
>>> It should be noted that this current 1.1 draft says
>>> 8<------
>>> A particular implementation of UWS may choose to allow the parameters to be
>>> updated (but not created) after the initial job creation step, before the
>>> PHASE is set to the executing state. It is up to the individual
>>> implementation to specify exactly how these parameters may be updated, but
>>> good practice (in the REST binding) would be to choose one of the following
>>> options.
>>>
>>> 	• HTTP POST an application/x-www-form-urlencoded parameter name, value
>>> pair to either
>>> 		• /{jobs}/{job-id}
>>> 		• /{jobs}/{job-id}/parameters
>>> 	• HTTP PUT the parameter value to
>>> /{jobs}/{job-id}/parameters/(parameter-name)
>>> 8<------
>>>
>>> i.e. it is not very prescriptive, only suggestive - From what I remember it
>>> was rather difficult to find common ground between those who wanted lots of
>>> flexibility and those who thought that there are too many options for
>>> setting parameters. For my part I would like more simplicity and clarity and
>>> would definitely like to ban some of the possibilities.
>>>
>>> Paul
>>>
>>>
>>>
>>>
>>> .
>>>
>> -- 
>>
>> 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)
>>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/


-- 
-------------------------------------------------------------------------
                            Pierre Le Sidaner
                         Observatoire de Paris

Division Informatique de l'Observatoire
Observatoire Virtuel 01 40 51 20 89
61, avenue de l'Observatoire 75014 Paris

mailto:pierre.lesidaner at obspm.fr
http://vo-web.obspm.fr

--------------------------------------------------------------------------