[Koha-devel] POC of a new plugin system

Tue May 17 02:26:18 CEST 2016

Thanks for this email, Julian. Re-reading the email thread on
"Country-specific forks?" was enlightening.

I think the discussion was a bit confused though. I think some people were
talking about adding custom modules/components, while other people were
talking about plugging existing components. 

It seems to me that Koha::NorwegianPatronDB relates to patron management and
possibly authentication. In that case, it probably needs to plug the
existing patron and authentication systems, I think, rather than adding new
modules/components. I think the authentication module/component would be a
good candidate for adding plugins. 

I really like the idea of adding custom modules/components/plugins though.
Whether that's as part of the REST API (perhaps as an "extension"), adding a
different cataloguing module (like Rancor), adding a different search engine
(like ElasticSearch), adding new "Tools". 

Personally, I like the idea of re-thinking the architecture of Koha, and
doing something service-oriented or microservice-oriented. Something loosely
coupled. There could be a core automatically testable API. Every new
component would have to pass the core tests or fail. If a new component
needs something more from the core, then a patch for core may need to be
made. In other words, a cataloguing service or an import service would need
to be able to produce a record that passes the core API's tests. If a
component needs to send an email, it sends a request to the core API which
dispatches to the email/messaging component. 

It could also allow for different OPAC implementations. If the OPAC relied
upon an API, you could provide an OPAC in Drupal, Wordpress, corporate
websites, etc. This also solves some country-specific and localization
issues, as you get the data from Koha and then present it as you desire.
Plus, you could built country-specific features and make calls to that
"extension API". 

On a related note, I've also been working on a "job server" called Icarus
[1] . I've written it from scratch in Perl, but it could just as easily be
replaced with a different job server. It's pluggable and lets you run
anything you want in the background. I've created it for doing OAI-PMH
harvesting, but its uses could be many. It could easily replace Tools > Task
scheduler for sending report results via email. It could also be used for
other components to do things (e.g. nightly exports, patron sync, etc) in
the background without adding cronjobs. 

I suppose my overall point is... let's use a service oriented architecture
that relies on stable core APIs and allows for custom services/modules to be
added with ease, and make certain services (e.g. authentication) pluggable
as there are many different implementations you might want to have alongside
each other rather than replacing each other.

In conclusion, sounds exciting, Julian!

[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662

David Cook
Systems Librarian

Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007

Office: 02 9212 0899
Direct: 02 8005 0595

> -----Original Message-----
> From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-
> bounces at lists.koha-community.org] On Behalf Of Julian Maurice
> Sent: Tuesday, 17 May 2016 3:14 AM
> To: koha-devel at lists.koha-community.org
> Subject: [Koha-devel] POC of a new plugin system
> 
> Hi all,
> 
> A couple of months ago, we talked about how great it would be to have a
> more powerful plugin system (thread subject was "Country-specific forks"
> [1]).
> 
> The current implementation have some problems. For instance, it's not
> possible to properly manage plugins with a VCS (bug 15879 [2] try to
address
> this issue)
> 
> Alex and I have started to write a new plugin system, as an attempt to fix
the
> problems of the current implementation. It's still in a very "alpha"
status, but
> we would like to hear what you think of it.
> 
> Code is in BibLibre repository, branch koha-module-poc:
>   http://git.biblibre.com/biblibre/kohac.git
> 
> Features:
> * VCS-compatible (every directory under the modules directory and
> containing a module.yaml file is a module)
> * Allow modules to define custom "URL routes" (see module/router.pl)
> * Allow modules to modify the intranet top menu (so they can add a link to
> their custom routes)
> * Allow modules to have their own TT include files and TT plugins
> 
> A sample module was made to demonstrate these features:
>   http://git.biblibre.com/biblibre/koha-module-LoremIpsum.git
> 
> This module creates a new page which display some "lorem ipsum" text
> fetched from loripsum.net, and add a link to this page in the intranet top
> menu. Very basic but it shows how it works.
> 
> Quick start:
> 1. git remote add biblibre http://git.biblibre.com/biblibre/kohac.git
> 2. git checkout -b koha-module-poc biblibre/koha-module-poc 3.
> installer/data/mysql/updatedatabase.pl
> 4. misc/devel/update_dbix_class_files.pl
> 5. mkdir /path/to/modules
> 6. Edit $KOHA_CONF and add a line
>      <modules_dir>/path/to/modules</modules_dir>
> 7. cd /path/to/modules && git clone
> http://git.biblibre.com/biblibre/koha-module-LoremIpsum.git LoremIpsum
> (note: the directory's name is important) 8. Go to Administration >
Modules
> 9. Enable the module LoremIpsum 10. You should now see a new link in the
> top menu
> 
> Final note: we would like to work on it during the hackfest in
Thessaloniki, so
> if you are interested, let us know!
> 
> 
> [1]
> http://lists.koha-community.org/pipermail/koha-devel/2016-
> February/042382.html
> [2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15879
> 
> --
> Julian Maurice <julian.maurice at biblibre.com> BibLibre
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : http://git.koha-
> community.org/ bugs : http://bugs.koha-community.org/