-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Julian Maurice Sent: Tuesday, 17 May 2016 3:14 AM To: koha-devel@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
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 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@biblibre.com> BibLibre _______________________________________________ Koha-devel mailing list Koha-devel@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/