Expressing service deprecation?

[Brian Major]

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:

> 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
convention.


>
> 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,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20170613/36a990fb/attachment.html>