[Bug 27423] New: ILS-DI should be deprecated and functions moved to REST API
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 Bug ID: 27423 Summary: ILS-DI should be deprecated and functions moved to REST API Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs@lists.koha-community.org Reporter: nick@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au, | |fridolin.somers@biblibre.co | |m, | |jonathan.druart@bugs.koha-c | |ommunity.org, | |julian.maurice@biblibre.com | |, katrin.fischer@bsz-bw.de, | |kyle@bywatersolutions.com, | |m.de.rooy@rijksmuseum.nl, | |martin.renvoize@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.suzuki@biblibre.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 Magnus Enger <magnus@libriotech.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |magnus@libriotech.no -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #1 from Julian Maurice <julian.maurice@biblibre.com> --- 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... :) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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`? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #4 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (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... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- 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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #8 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- @Nick, if you're doing work on this, I'd be happy to do some testing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #12 from Nick Clemens <nick@bywatersolutions.com> --- (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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #13 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- 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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #14 from David Cook <dcook@prosentient.com.au> --- 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #15 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.poulain@biblibre.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=36561 --- Comment #16 from David Cook <dcook@prosentient.com.au> --- @Nick, did you guys come up with anything in the end? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #17 from Nick Clemens <nick@bywatersolutions.com> --- (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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27423 --- Comment #18 from David Cook <dcook@prosentient.com.au> --- (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). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org