That’s cool to hear, Marcel! Happy to share my thoughts.
A couple reasons I don’t want to use plugins:
- I don’t want to turn on Koha plugins for 100+ different Koha instances around the world.
- Overall, I think the Koha plugin system is insecure, and allows library staff too much control over the system. I typically keep it disabled with only a few exceptions. (I’ve opened a few bugs and provided a few patches for improving plugin security but they haven’t gone anywhere yet on Bugzilla.)
- I also wouldn’t want library staff to potentially meddle with the plugin I install. I think this plugin is really a system plugin rather than a user plugin. It should be invisible to library staff.
- I’d be looking to install/upgrade plugin code on 100+ different Koha instances which presents a maintenance challenge
- While I think some vendors use Ansible to do this, I’m not currently satisfied with the CLI plugin tooling for install/upgrade/downgrade/uninstall. (I’ve done some work on this as well on Bugzilla but the work hasn’t progressed and it’s dropped down my priority list.)
i. Using an Ansible push also isn’t an option in some security/operational contexts. In some contexts, you provide artifacts and leave deployment/operations up to a different team
- I rather install this “system plugin” 1 time on a server rather than X times. (I think this is something some other vendors have struggled with and worked around as well.)
- I’d need to change the instance creation process to install this plugin as well. (Not the end of the world but a bit annoying and introduces more room for errors.)
That said, the hooks already exist, so I can see the appeal, and I can see how they’d work well for other people, especially with fewer Koha instances to manage.
I suppose it mostly comes down to control, security, and maintenance/management.
Also, other systems like Dspace and Fedora write out to message queues out of the box, and it makes it easy to add integrations to them without touching the core application at all. It would be great if Koha could do the same without needing a plugin. (If it were core functionality, we could use it for indexing as well and replace the “zebraqueue”.)
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Marcel de Rooy
Sent: Thursday, 2 December 2021 6:15 PM
To: 'koha-devel' <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] [Changed topic] Action hooks
> I also have a use case where I want to send Koha biblio data elsewhere on create/update/delete, but Koha plugins won't be suitable. I've been thinking that it would be good to publish a message to a RabbitMQ topic on biblio create/update/delete. In fact, that could potentially replace the existing C4::Biblio::_after_biblio_action_hooks and Koha::Item::_after_item_action_hooks functions, and then the background_jobs_worker.pl or some other work could invoke the plugins.
I am running plugins to do the same for some time already. They are pushing these crud actions to a message queue. Works fine for me. Could you tell what makes plugins not suitable for that task?
|
