UWS POST PHASE=RUN

[Patrick Dowler]

On 04/11/14 03:04 AM, Grégory Mantelet wrote:
>       3/ other
> Only the JDL can be provided. It is a blob, XML or other kind of
> document which is completely opaque and could not be interpreted by the
> UWS server. This document must be stored as provided and with no
> interpretation of the UWS server. It implies that UWS parameters
> (duration, destruction, ...) can not be provided in the initial POST and
> if the user want to modify their default value, it must do it after
> creation and before execution with one or several POST in
> "application/x-www-form-urlencoded".

> So, I think that only the two first methods must be proposed, even if I
> understand the third one. The two first methods are simple, well-known
> and let cover all possible cases, whereas 3/ allows just one opaque file
> - eventually large - to be submitted and without any possibility to
> provide UWS parameters in the initial POST.


But banning #3 doesn't permit the existing vospace usage of POSTing an 
xml document which gets stored under jobInfo. That usage is very well 
defined (more so than the parameters we added to support DAL): POST a 
document during job creation, I'm not sure if it is supported or not, 
but if one thought about modifying a job in the PENDING phase the only 
plausible way is to think about it is to POST a new document to the 
/obs/<jobid>/jobInfo and update that resource.

As for "opaque": yes, the UWS library/infrastructure treats it as a blob 
but clearly not the whole server: at some point the job execution code 
has to grok the content and perform the specified work. I see no 
problems with this at all.

Back to something I mentioned yesterday: the <parameters> stuff was 
added to UWS to support DAL (TAP specifically) pretty late in the 
process and iirc Paul was against it. In retrospect it was probably rigt 
to add it but we did it the wrong way: we should have added a 
parameter-based JDL such that the <parameters> element went in the job 
under jobInfo rather than as an alternative. That would have correctly 
matched the intent. And it could have kept the content of <parameters> 
outside the core UWS schema and thus removed the complexity of 
"modifying a job".  I am certain that Paul argued this very thing at the 
interop in Strasbourg.

So, I am against any change that bans POSTing a document, including 
something like JDL=<document in string form> and stuffing it into a 
parameter. It would severely limit the usefulness of UWS. Also, I'm not 
certain that banning combining a document and parameters is really 
necessary: someone could define a job with a document *and* use of 
parameters as options... I could see TAP having been designed to take 
the query as a document and use parameters for the control features 
(MAXREC, FORMAT, etc)... not suggesting it should be that waym but it 
could have been and some other spec could be and it would be perfectly 
sensible.

-- 

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

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