Expressing service deprecation?
major.brian at gmail.com
Tue Jun 13 23:45:37 CEST 2017
Hi Markus, thanks for the reply. Some comments below.
On Tue, Jun 13, 2017 at 12:48 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:
> On Mon, Jun 12, 2017 at 05:10:16PM -0700, Brian Major wrote:
> > I am wondering if a mechanism within registry exists that allows
> > to indicate that a particular service is deprecated. And, if so, allows
> > for the recommendation of an alternate service.
> I suspect the entire question arises in the context of VOSpace, and my
> shallow reading of it suggests that for that, there may be a
> requirement for this kind of thing (synctrans-2.0 vs synctrans-2.1
> perhaps?). If so, I'd be happy to help in working out the details.
Yes, VOSpace 2.1 has introduced a new standardID for the synctrans
endpoint, but wasn't the driver behind my question. (But, for the record:
to support 2.0 clients, our VOSpace 2.1/2.0 service does indeed list two
capabilities for synctrans functionality--the 2.0 and 2.1 versions.)
This question was more about how to do non-compatible (major) service
updates (to any type of service) without forcing users to get the latest
client immediately. The strategy would be:
- Publish a service that implements version (e.g.) 1.0 of a capability.
- Distribute a client (non browser) that uses the VOSI capabilities to find
the 1.0 capability.
- Re-publish the service so that it supports version 1.0 and a new 2.0
version of the capability. Existing clients continue to work because they
use the 1.0 capability.
- Inform users that there is a new version of the client available and they
have a period of X months to get it before it stops working.
- After X months, remove the 1.0 version of the service to make way for
(possibly) more new versions.
If the client finds that the standardID(s) it support for a certain feature
are deprecated, it can be more proactive about getting the new version into
the hands of the user. At the minimum, it can issue a warning. But a
sophisticated client could even try to upgrade itself.
> There is another aspect to this question, though:
> > I thought I had once seen 'replacedBy' attribute somewhere but cannot
> > it. (Maybe I was thinking of the mirroring support). If people think
> > is a good idea, perhaps such an attribute belongs at the capability
> As I said, on the capability level I'd say the informal convention
> "everything but the newest version is deprecated" is enough until
> proven insufficient.
I agree--but determining which is the newest currently relies on naming
> However, if you want to shut down a service at some point, you could
> make a *different* resource record and declare it the old service's
> replacement; that's not really dependent on different protocol
> versions, there could be many reasons for moving services. You need
> VOResource 1.1 (RFC now! Hurry!) to do that, though. The sketch is:
> Old Service:
> <relatedResource ivo-id="ivo://new.provider/newservice"
> >New Service</relatedResource>
> New Service:
> <relatedResource ivo-id="ivo://old.provider/oldservice"
> >Old Service</relatedResource>
> Clients could take the presence of an isContinuedBy as an indication
> that a service is deprecated. I'm not sure, though, I'd like to make
> a recommendation to check for isContinuedBy relationships as a part
> of normal discovery operations.
This all sounds like the right support for executing a release strategy
like the one I outlined above. However, I wonder if a potentially frequent
cycle of releases makes for too dynamic of data for a resource record. If
this information was at the capability level then, through VOSI
capabilities, service operators could have more control of the exact timing
of the availability of new capabilities.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the registry