UWS 1.1 alternative, WAIT

[Paul Harrison]

On 2014-06 -18, at 11:07, Dave Morris <dave.morris at metagrid.co.uk> wrote:

> Hiya,
> 
> On 2014-06-18 08:07, Paul Harrison wrote:
>> On 2014-06 -17, at 13:34, Dave Morris <dave.morris at metagrid.co.uk> wrote:
>> I think that there is a reasonable argument for making the blocking
>> endpoint /jobs/{jobid} with the ?WAIT parameter from your earlier
>> suggestion in this thread - I cannot see a big downside to that at the
>> moment (apart from making it a little more difficult for clients to
>> detect lack of 1.1 capability)
> 
> You had convinced me that a separate endpoint made more sense.

I meant to convince you that a single (rather than necessarily separate) endpoint rather than many potentially blocking was better…..

> 
> You are right - discovery would be a problem.
> 
> Following Brian's email about XML validation and major/minor versions etc. I've been thinking about reliability and robustness in our designs.
> 
> We already have a perfectly good discovery mechanism, but we tend not to use it.
> 
> Should we just make this a new capability ?
> 
> The UWS-1.1 specification defines the behaviour of the blocking endpoint, and says that IF a service wants to provide this, then they should list it as a capability using [this] URI ?
> 

If this blocking is in UWS 1.1 then it will be mandatory - then a client could just use the difference between the overall UWS 1.0 and UWS 1.1 capability to distinguish by looking at VOSI capabilities - I was just trying to find an easy way for a client to reason between the versions simply from probing the UWS interface itself, but I think that would be a “nice to have” feature rather than essential.

Paul.