capability and @version [was: Home for the UWS Registry Extension?]

[Patrick Dowler]

We have some services where we provide client tools; when we make some sort
of incompatible service change we add a new endpoint (usually a new
capability because we are using major.minor versioning of the standardID
and matching exactly) and run with both versions for some period of time
(until users have updated clients). In this kind of usage (custom clients)
a specific version of a client only looks for one version of the capability
so as users upgrade client s/w usage moved from the old to the new version.
We have not had a need to make clients check minor versions and act
differently.

We could do the same with a stable standardID and an @version attr on the
interface, which is what the UWSRegExt doc should have said... that
approach would let the service advertise new (optional) features that the
client could use, so that fits the IVOA minor-version of a service (don't
break clients) usage. I never had a need for multiple interfaces with same
standardID and different versions because keeping the previous version
interface in this case made service more complex and was of no value to
users. There could be a use case, but we've evolved some services through
many changes and never wanted to do that.

my 2c,

PS-These are not IVOA services, just custom web services  where clients use
VOSI-capabilities to figure out to how to invoke the service

On 25 June 2018 at 23:46, Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
wrote:

> Hi Grid,
>
> On Mon, Jun 25, 2018 at 02:13:34PM +0100, Mark Taylor wrote:
> > On Mon, 25 Jun 2018, Markus Demleitner wrote:
> > > As long as we have not identified strong use cases to discover by
> > > minor version, my take would be: interfaces declare the highest
> > > version they implement.  That would cover the "I need some extra
> > > feature only available since version 1.2" use case, which currently
> > > is the only discovery use case I find somewhat credible.
> >
> > First, we're not just talking about discovery in the registry here,
> > this also applies to enumerating interfaces in a service's capabilities
> > endpoint, and one can imagine 'discovery' use cases in that context
> > that are a little bit more flexible.  I agree that it's hard to
>
> Yes, true.  Again, we'll have to figure out the use cases and
> requirements for, well, let's call it the VOSI case.
>
> > advertise in the /capabilities document both a 1.1 and a 1.2
> > version - e.g. because the implementation code has changed
> > significantly between the two (they have different bugs) and
> > they want to allow the (well-informed) user to choose between them.
>
> Data providers out there: Have you found it necessary to do that?
> Based on your previous experience: Do you anticipate that need?
>
> > Second, I don't think this applies only to minor versions.
> > If at some point in the coming decades we have a TAP 2.0
> > then there will be reasonable discovery use cases that wish to
> > distinguish between 1.* and 2.* versions.
>
> Current practice with SIA (which I think is sane) is that a major
> version gets a new standards record with an identifier of its own and
> therefore is, as far as the registry goes, completely independent of
> the previous major version.  They would therefore have a different
> capability element -- which seems quite appropriate to me.
>
> But I may be fooling myself -- perhaps we should ask on DAL and Apps
> if people think the SIA major versioning technique works for them?
>
>
>        -- Markus
>



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20180626/10eff6b1/attachment.html>