prototype TAP-1.1 service

[Mark Taylor]

I didn't say it explicitly in my message but obviously, I understand
the point that schema namespace version changes are a massive pain
and very likely cause trouble somewhere or other.  So I have sympathy
with you not changing the namespace right now.

But from a practical point of view, this does leave clients with
no way to determine whether they're talking to a UWS 1.1 service
or not, and assuming that blocking is supported when it's not will
cause trouble, or at the least some rather fiddly client-side
implementation code.  If there were some other way to flag
UWS1.1-ness (or at least blocking support) it would sidestep that.

On Tue, 2 Jun 2015, Patrick Dowler wrote:

> 
> Yeah, I didn't make that change because the documents themselves didn't
> actually change and I was worried about breaking clients that look for a
> specific namespace (after breaking one that looked for VOTable-1.2 from our
> TAP service).
> 
> I was intending to update it to UWS-1.1 when I actually needed to (eg when I
> actually had jobs in the ARCHIVED phase)... hmmm. I'll need to evaluate the
> impact.
> 
> Pat
> 
> On 02/06/15 07:04 AM, Mark Taylor wrote:
> > Pat (again),
> > 
> > On Wed, 27 May 2015, Patrick Dowler wrote:
> > 
> > > I have updated the CADC TAP service with some TAP-1.1 goodies:
> > > 
> > ...
> > > 
> > > 4. The async jobs now support the UWS blocking query (WAIT) with a current
> > > maximum wait time of 60 (sec), at which point you just get the job in the
> > > current phase (phase when the wait started). It isn't a very fancy
> > > implementation: it just does some server side polling of the job phase
> > > with
> > > increasing delta (1, 2, 4, 8 sec then stays at 8) because we have 4 web
> > > servers and no distributed event notification system in place to wake up
> > > blockers on a different server from the one actually running the job. But,
> > > I
> > > think this is OK for what it does, which is relieve the client from doing
> > > polling with all the connection overhead.
> > 
> > Paul's original posting on this said:
> > 
> > On Tue, 19 May 2015, Paul Harrison wrote:
> > 
> > > I believe that there is only one outstanding issue in this document
> > > in section 2.2.1.1
> > > (http://volute.googlecode.com/svn/trunk/projects/grid/uws/doc/UWS.html#blocking)
> > > highlighted in yellow. It concerns how other standards might signal which
> > > version of UWS that they are using. My current feeling is to remove this
> > > text entirely and leave it up to the other standard documents to signal
> > > the mechanism that they want to use. I think that part of the cause for
> > > this versioning issue to come up was the lack of clarity of the namespace
> > > for the UWS schema - which is now addressed by the release of a schema
> > > with a new 1.1 namespace - therefore it is safe to remove this issue
> > > from the UWS specification. Any objections?
> > 
> > However it looks to me like the job documents at service/async/(job-id)
> > are still in the http://www.ivoa.net/xml/UWS/v1.0 namespace.
> > Is that true, or am I looking at the wrong thing?
> > 
> > As long as that's the case, I don't think there's any good way
> > for me as a client to find out I'm talking to a UWS 1.1 service,
> > so I'm not going to be able to implement client-side blocking
> > functionality.
> > 
> > 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/
> > .
> > 
> 
> -- 
> 
> 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)
> 

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