Bug 27423 - ILS-DI should be deprecated and functions moved to REST API
Summary: ILS-DI should be deprecated and functions moved to REST API
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Web services (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-13 14:19 UTC by Nick Clemens
Modified: 2021-01-26 08:57 UTC (History)
11 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens 2021-01-13 14:19:21 UTC
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
Comment 1 Julian Maurice 2021-01-13 14:30:12 UTC
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... :)
Comment 2 Katrin Fischer 2021-01-13 14:45:33 UTC
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.
Comment 3 Katrin Fischer 2021-01-13 14:49:32 UTC
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`?
Comment 4 Arthur Suzuki 2021-01-13 14:50:18 UTC
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.
Comment 5 David Cook 2021-01-14 04:02:19 UTC
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.
Comment 6 David Cook 2021-01-14 04:11:28 UTC
(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...
Comment 7 David Cook 2021-01-14 04:13:49 UTC
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?
Comment 8 Arthur Suzuki 2021-01-14 10:02:09 UTC
(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.
Comment 9 David Cook 2021-01-14 23:52:09 UTC
(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.
Comment 10 David Cook 2021-01-14 23:54:06 UTC
(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.
Comment 11 David Cook 2021-01-14 23:54:23 UTC
@Nick, if you're doing work on this, I'd be happy to do some testing.
Comment 12 Nick Clemens 2021-01-15 12:01:51 UTC
(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
Comment 13 Arthur Suzuki 2021-01-15 12:54:16 UTC
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?
Comment 14 David Cook 2021-01-18 01:26:54 UTC Comment hidden (obsolete)
Comment 15 David Cook 2021-01-18 01:31:03 UTC
(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.