Expressing service deprecation?

Brian Major major.brian at
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> wrote:

> Hi,
> On Mon, Jun 12, 2017 at 05:10:16PM -0700, Brian Major wrote:
> > I am wondering if a mechanism within registry exists that allows
> providers
> > 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
> find
> > it.  (Maybe I was thinking of the mirroring support).  If people think
> this
> > is a good idea, perhaps such an attribute belongs at the capability
> level?
> 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:
>   <Resource>
>     <identifier>ivo://old.provider/oldservice</identifer>
>     ...
>     <relationship>
>       <relationshipType>isContinuedBy</relationshipType>
>       <relatedResource ivo-id="ivo://new.provider/newservice"
>         >New Service</relatedResource>
>     </relationship>
>   </Resource>
> New Service:
>   <Resource>
>     <identifier>ivo://new.provider/newservice</identifer>
>     ...
>     <relationship>
>       <relationshipType>Continues</relationshipType>
>       <relatedResource ivo-id="ivo://old.provider/oldservice"
>         >Old Service</relatedResource>
>     </relationship>
>   </Resource>
> 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.


Thanks again,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the registry mailing list