<div dir="ltr">Hi Markus, thanks for the reply. Some comments below.<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 13, 2017 at 12:48 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On Mon, Jun 12, 2017 at 05:10:16PM -0700, Brian Major wrote:<br>
> I am wondering if a mechanism within registry exists that allows providers<br>
> to indicate that a particular service is deprecated. And, if so, allows<br>
> for the recommendation of an alternate service.<br>
><br></span></blockquote><div><br></div><div>[...]</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>[...]<br>
<br>
I suspect the entire question arises in the context of VOSpace, and my<br>
shallow reading of it suggests that for that, there may be a<br>
requirement for this kind of thing (synctrans-2.0 vs synctrans-2.1<br>
perhaps?). If so, I'd be happy to help in working out the details.<br></blockquote><div><br></div><div>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.)</div><div><br></div><div>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:</div><div><br></div><div>- Publish a service that implements version (e.g.) 1.0 of a capability.</div><div>- Distribute a client (non browser) that uses the VOSI capabilities to find the 1.0 capability.</div><div>- 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.</div><div>- 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.</div><div>- After X months, remove the 1.0 version of the service to make way for (possibly) more new versions.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There is another aspect to this question, though:<br>
<span class=""><br>
> I thought I had once seen 'replacedBy' attribute somewhere but cannot find<br>
> it. (Maybe I was thinking of the mirroring support). If people think this<br>
> is a good idea, perhaps such an attribute belongs at the capability level?<br>
<br>
</span>As I said, on the capability level I'd say the informal convention<br>
"everything but the newest version is deprecated" is enough until<br>
proven insufficient.<br></blockquote><div><br></div><div>I agree--but determining which is the newest currently relies on naming convention. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, if you want to shut down a service at some point, you could<br>
make a *different* resource record and declare it the old service's<br>
replacement; that's not really dependent on different protocol<br>
versions, there could be many reasons for moving services. You need<br>
VOResource 1.1 (RFC now! Hurry!) to do that, though. The sketch is:<br>
<br>
Old Service:<br>
<br>
<Resource><br>
<identifier>ivo://old.<wbr>provider/oldservice</<wbr>identifer><br>
...<br>
<relationship><br>
<relationshipType><wbr>isContinuedBy</<wbr>relationshipType><br>
<relatedResource ivo-id="ivo://new.provider/<wbr>newservice"<br>
>New Service</relatedResource><br>
</relationship><br>
</Resource><br>
<br>
New Service:<br>
<br>
<Resource><br>
<identifier>ivo://new.<wbr>provider/newservice</<wbr>identifer><br>
...<br>
<relationship><br>
<relationshipType>Continues</<wbr>relationshipType><br>
<relatedResource ivo-id="ivo://old.provider/<wbr>oldservice"<br>
>Old Service</relatedResource><br>
</relationship><br>
</Resource><br>
<br>
Clients could take the presence of an isContinuedBy as an indication<br>
that a service is deprecated. I'm not sure, though, I'd like to make<br>
a recommendation to check for isContinuedBy relationships as a part<br>
of normal discovery operations.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>[...] </div><div><br></div><div>Thanks again,</div><div>Brian </div></div><br></div></div>