This is just to start a discussion. I was trying to find the specifications for ILS-DI, but it seems that they don't exist? https://www.diglib.org/project-update-ils-di/ The links on that page indicate that no updates have been made since 2011? There seems to be a fair amount of use of ILS-DI so I don't think we can disable it until it is replicated, but I do think we should indicate that it will not be updated and eventually should be removed
I found https://old.diglib.org/architectures/ilsdi/DLF_ILS_Discovery_1.1.pdf The fact that it can only be found on an "old." domain tells a lot about its status... :)
AFAIK ILS-DI is used in the available VUfind-Driver among other things. I'd be careful to remove it until we have something that is as well documented and feature complete to replace it. There has also been a steady stream of patches still for ILS-DI over the last years, even some enh beyond the scope of the initial documentation.
I think the scope of ILS-DI and the REST-API is also different. This is an API for discovery interfaces that's supposed to not allow more than the OPAC user should be able to do. They can place a hold... but they cannot manipulate a holds data. They can look up a patron, but not change their data etc. I believe the REST API as is might not serve well here as it allows too much and you'd want to have something more limited to be used by external catalog/discovery providers specifically`?
Hi Nick, Although no new functionality are added to ILS-DI, it's in use by a lot of software, most discovery tools and frontend softwares including : - VuFind - BlackLight - Summon (Proquest) - EDS (Ebsco) - Bokeh (AFI-BibLibre) So it would break backward compatibility with those. Also, no new functionality but quality gets improved (like, circulation rules which used not to behave like OPAC are now taken into account when using ILS-DI). I fear this testing and quality assessment job is lost, and some instability brought instead. For me, it's ok to say we won't bring new features in, but maintenance and access to the API has to be kept for backward compatibility reason, eventually forwarding ILS-DI calls to the API when all functions are replicated.
Hmm, yeah maybe we should rebrand this one as "Reproduce ILS-DI functionality in REST API" and then have a separate bug for "Deprecate ILS-DI", which has Bug 27423 as a dependency.
(In reply to Katrin Fischer from comment #3) > I think the scope of ILS-DI and the REST-API is also different. > > This is an API for discovery interfaces that's supposed to not allow more > than the OPAC user should be able to do. They can place a hold... but they > cannot manipulate a holds data. They can look up a patron, but not change > their data etc. > > I believe the REST API as is might not serve well here as it allows too much > and you'd want to have something more limited to be used by external > catalog/discovery providers specifically`? Those are interesting points too. I have been thinking that Koha is due for a review of its authorization system...
To play devil's advocate, what's the main reasons for removing the ILS-DI API? Is it due to security issues? Maintainability? Code duplication? Personally, I dislike how it's only IP restricted. I would like more robust authentication. While I know that third-parties use the ILS-DI API, I don't know the history there. Did they develop client tools for generic ILS-DI APIs or did they always develop specifically for Koha's implementation of ILS-DI?
(In reply to David Cook from comment #7) > To play devil's advocate, what's the main reasons for removing the ILS-DI > API? > > Is it due to security issues? Maintainability? Code duplication? > > Personally, I dislike how it's only IP restricted. I would like more robust > authentication. If implementing more robust auth, then client/third-party software will have to adapt their connectors specifically for Koha I'd say, code duplication is a point, some bugs are working on "merging" code back from the interfaces to C4 or Koha namespace. Thinking of bz25408 (which I rebased this night) but there are others pushing in that way. This is also a good opportunity to centralize some controls on sysprefs and circ rules, things which are also beneficial for Staff, Opac and API interfaces. From my point of view, ILS-DI is an opportunity to spot things and have a look on other stuff. > > While I know that third-parties use the ILS-DI API, I don't know the history > there. Did they develop client tools for generic ILS-DI APIs or did they > always develop specifically for Koha's implementation of ILS-DI? Speaking for Bokeh (php) we have an "AbstractILSDIService" class which we extends to any library software using ILS-DI. Small differences in the implementations are handled by overloading specific calls or properties.
(In reply to Arthur Suzuki from comment #8) > If implementing more robust auth, then client/third-party software will have > to adapt their connectors specifically for Koha Well, not necessarily specifically for Koha, but for whatever auth scheme we use. (Although that's just "six of one, half a dozen of another".) But yeah that's on my mind too. That's a tricky one.
(In reply to David Cook from comment #9) > (In reply to Arthur Suzuki from comment #8) > > If implementing more robust auth, then client/third-party software will have > > to adapt their connectors specifically for Koha > > Well, not necessarily specifically for Koha, but for whatever auth scheme we > use. (Although that's just "six of one, half a dozen of another".) > > But yeah that's on my mind too. That's a tricky one. That being said, deprecate isn't the same as disable. It would be nice to build up a replacement API that could be used instead of ILS-DI for systems that can support it. I imagine discovery systems like Aspen Discovery and VuFind would be interested in a more modern and powerful API.
@Nick, if you're doing work on this, I'd be happy to do some testing.
(In reply to David Cook from comment #11) > @Nick, if you're doing work on this, I'd be happy to do some testing. Nothing currently, but we are looking into things here, I will let you know when we have anything ready
Does anyone has already tried to contact digibib google group? if ILS-DI is getting old and unsecure and somehow deprecated, maybe there is a joined effort to make, not only for Koha but for other SIGB's as well?
Demian Katz mentions something about "the KohaILSDI version isn't actually directly tied to the ILS-DI API in any way". I wonder what he meant by that... https://vufind.org/jira/browse/VUFIND-1418
(In reply to Arthur Suzuki from comment #13) > Does anyone has already tried to contact digibib google group? > if ILS-DI is getting old and unsecure and somehow deprecated, > maybe there is a joined effort to make, not only for Koha but for other > SIGB's as well? digibib? Do you mean diglib? It looks like the ILS-DI group became suddenly defunct in November 2011: https://sites.google.com/site/ilsinterop/meeting-minutes Probably best off trying to get in touch with Karen Coombs (OCLC) or Demian Katz (maybe via VuFind) I reckon.
@Nick, did you guys come up with anything in the end?
(In reply to David Cook from comment #16) > @Nick, did you guys come up with anything in the end? Nothing directly, really we have just indicated a preference for the API, and work with vendors to use the APi over ILS-DI where we can. We now have CRUD for biblios/items - so harvesting/get 'can' be done that way Patron API provides most of the functionality renewals and holds can be done via API We would need to dig a bit to make sure functionality is 1:1, but we are closed than we were
(In reply to Nick Clemens from comment #17) > (In reply to David Cook from comment #16) > > @Nick, did you guys come up with anything in the end? > > Nothing directly, really we have just indicated a preference for the API, > and work with vendors to use the APi over ILS-DI where we can. > > We now have CRUD for biblios/items - so harvesting/get 'can' be done that way > Patron API provides most of the functionality > renewals and holds can be done via API > > We would need to dig a bit to make sure functionality is 1:1, but we are > closed than we were I've noticed that the Patron API provides a lot of the functionality, although it also provides a lot more privilege than the ILS-DI did at the patron level, which makes me a bit uncomfortable. Are you using the REST API for authentication/validation now instead of ILS-DI? I'm hoping to change the permission for that to be more restrictive (bug 36561).