UWS 1.1

[Mark Taylor]

Grid et al.,

sorry for the delayed input on this, I was on holiday last week.

On Tue, 26 May 2015, Patrick Dowler wrote:

> 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.

Just to say that I agree with this too. I am fully expecting
to deal routinely with 'early' server returns from the blocking
poll that do not correspond to a change in phase.  I haven't
written the code yet, but I'd expect to put the call in a loop
like that used for a java Object.wait():

    while ( ! isFinishedPhase() ) {
       blocking_poll()
    }

Given the text in the blocking section of UWS 1.1, I think all clients
(including web pages) have to be able to do this, so I'd say that
Gregory's request redirection idea, while sort of neat, looks to me
like unnecessary complication.

> 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.

This reasoning is plausible enough, though I also note that there's
no useful role for explicitly specifying WAIT=0 that waits for
zero seconds, since you could just omit the WAIT parameter for the
same effect.  But either way, obviously implementing it as you
describe would only be permissible if the UWS PR text ends up
being changed accordingly.

Mark

--
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/