UWS 1.1
Patrick Dowler
patrick.dowler at nrc-cnrc.gc.ca
Tue May 26 20:28:34 CEST 2015
On 26/05/15 02:38 AM, Paul Harrison wrote:
>> Well, this is quite fine if the client is a browser - it is totally transparent - but another client (like Topcat) should know about that trick. Honestly, I am not keen with this idea although it limits the resources consumption on server side by avoiding real unlimited wait but by doing like it does. The other solution, as Pat said, is to set a timeout (= max server waiting time). I would certainly do the same, except if the "request redirection" solution is fine for you.
> On of the central design features of UWS is that the server is allowed to make decisions that override the requests from the client in order to save resources - e.g. if the client asks for a destruction time 10 years in the future, the server is allowed to reply with 10 days (or whatever it thinks it can support as a maximum) seehttp://www.ivoa.net/documents/UWS/20101010/REC-UWS-1.0-20101010.html#DestructionTime
>
> A similar reasoning can be applied to WAIT times and indeed the 3rd paragraph of thehttp://volute.googlecode.com/svn/trunk/projects/grid/uws/doc/UWS.html#blocking section anticipates that the server might return earlier than the WAIT time if necessary and the client should be able to deal with this situation - i.e. read the returned PHASE, and not just assume that it has changed because the server has returned.
Agreed.
Although I think the client should be expected to deal with the redirect
correctly, they also have to be able to deal with a server that just
lets the wait run until there is an http timeout and they have to deal
with the server unblocking for a change they don't care about... in all
of that, I find I prefer the max wait time on the server side as it is
consistent with the rest of UWS and easiest to implement. But, I think
one could provide the convenience of the redirect without violating the
spec.
Another small fiddly bit: I did implement ?WAIT (with no value) to wait
until the max wait time, but I see no value in having WAIT=0 be special
and do the same thing... with http timeouts there are no particularly
useful wait times that are large enough that a client can't come up with
a normal value that expresses their actual interest and no one is really
interested in waiting forever :-) So, in my implementation WAIT=0 does
exactly that: waits for 0 seconds then returns.
--
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)
More information about the grid
mailing list