patrick.dowler at nrc-cnrc.gc.ca
Thu Jun 19 12:30:07 PDT 2008
On 2008-6-16 05:58, Paul Harrison wrote:
> Although the document might not make this explicit, the intention is
> that the "minimum" requirement is that a UWS service return XML for
> all of the job objects (excluding the individual results which may be
> returned in their "natural" mime type). I.e. MUST support the Accept:
> application/xml request header.
> The preliminary schema attached to the document would have the phase
> returned as
> <?xml version="1.0" encoding="UTF-8"?>
> <uws:phase xmlns:uws="http://www.ivoa.net/xml/UWS/v0.9">COMPLETED
> Additionally if the client indicates that it can accept html then the
> XHTML can be returned - as there is a strong desire to be able to
> drive these UWS from standard browsers. I am currently a little unsure
> how proscriptive we can attempt to be on the form that the XHTML
> takes, but I think it would be nice if we could find a way of
> guaranteeing that it works on as wide a range of browsers as possible
> - i.e. don't be too fancy with the HTML interface, and try to use
> browser specific features.
Moving along with my UWS implementation, I have stumbled into a few things:
1. redirect destination
In the case of being driven by the browser, it seems that the best response to
a POST (modification of the job) is to redirect to the job rather than to the
modified resource, for a couple of reasons:
- when I modify one resource or POST some new params while setting up the job,
it seems plausible that the service will modify other resources as well, such
as changing the quote, termination, or destruction as I specify input files.
Specifically, the quote and/or termination will likely go up if the inputs
are large, while a resource-constrained service may decrease the amount of
time until destruction... I can't see any way to prohibit POST from having
such side effects. So it seems better to show the user the new job state.
- if one did redirect to the specific resource (eg phase) the page would need
a link back to the job which the user would immediately click, or the user
would immediately hit the back button... to see the new job state and/or to
further modify (other) resources.
- in the implementation, I need 3 pages: one with a "create job" form, one
that displays/edits the job, and one to display the result list. If I also
need to render pages with just one sub-resource, it adds work/complexity and
additional page views and clicks with no apparent benefit
So the pattern would be to redirect to the job and always display the job. In
the XML output mode, I don't see any problem with the sub-resources being
addressable via GET (and returning the small XML document above); this would
be especially useful in polling the phase to watch for the transition from
EXECUTING to COMPLETED. But in general, the redirect-after-post would go to
2. Accept header
disclaimer: It seems quite likely that I do not understand the accept
Ok, the rules for interpretting this are pretty odd and to get the desired
behaviour (from firefox) I have to not follow the rules.
In the spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html),
the client can specify multiple mimetypes, each with a "q" value that
indicates priority. Highest priority is for the most specific type, so
Accept: text/*, text/html
means the client can take any text type but prefers text/html (more specific),
Accept: text/plain; q=0.5, text/html
means the client can take these two types but prefers txt/html over text/plain
(lower q value).
Now, firefox (version 2 at least) sends this (formatted for clarity)
which (for UWS) I interpret as:
xml (preferred) -- server can pick from the 3 variants
then text/html (q=0.9)
then text/plain (q=0.8)
Why firefox would prefer arbitrary XML to HTML is beyond me. Also, the q=0.5
on */* is completely redundant since it is also the least specific type and
hence automatically the lowest priority.
For now, I just look through there for text/html and if I find that I write
HTML. Otherwise, I write XML. Tools like curl just put Accept: */* since they
do not care (and hence get XML).
Any thoughts on either issue?
Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada | Gouvernement du Canada
5071 West Saanich Road | 5071, chemin West Saanich
Victoria, BC | Victoria (C.-B.)
More information about the grid