[Koha-devel] Koha Core anyone?
David Cook
dcook at prosentient.com.au
Fri Apr 20 02:24:22 CEST 2018
I’m excited by Julian’s work to move Koha into Mojolicious: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582. However, it makes me think we’re moving farther away from Srdjan’s multi-tenancy goal: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15562.
However, I was just thinking that maybe Koha Core is the answer there.
For those who have the resources to do single-tenant apps, move full-steam ahead with Mojolicious. For those who want or need to have multi-tenant apps, maybe create/keep a simple CGI Koha based on Koha Core. I think it would be cool to have a multitenant Mojolicous, but considering how Ruby on Rails has a library called Apartment for handling multi-tenancy, I don’t know how well we’d fare trying to do our own implementation in Koha.
What do people think?
Does multitenancy matter to anyone?
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of David Cook
Sent: Friday, 20 April 2018 9:29 AM
To: 'Kyle Hall' <kyle.m.hall at gmail.com>
Cc: 'Koha Devel' <koha-devel at lists.koha-community.org>; 'Benjamin Rokseth' <benjamin.rokseth at deichman.no>
Subject: Re: [Koha-devel] Koha Core anyone?
In other Perl apps, I’ve used Moose to do before/after hooks: http://search.cpan.org/~ether/Moose-2.2010/lib/Moose/Manual/MethodModifiers.pod#Before_and_after_Modifiers
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
From: Kyle Hall [mailto:kyle.m.hall at gmail.com]
Sent: Friday, 20 April 2018 3:38 AM
To: David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> >
Cc: Benjamin Rokseth <benjamin.rokseth at deichman.no <mailto:benjamin.rokseth at deichman.no> >; Koha Devel <koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >
Subject: Re: [Koha-devel] Koha Core anyone?
I wonder if a Decorator pattern would be useful. An even simpler situation would be to enable a before and after hook for each subroutine in Koha via plugins.
Kyle
<https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB>
http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )
On Tue, Apr 10, 2018 at 7:22 PM, David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > wrote:
It seems to me that the Deichman modules would become stale pretty quickly.
Although, if there were a Koha Core which was fairly simple, maybe there
wouldn't be many breaking changes introduced over time.
I have thought a bit about something like this before, although I was more
so interested in the OPAC. I thought it would be interesting to have a Koha
Core OPAC that worked out of the box, but have the core functionality
implemented with REST APIs so that people could embed Koha OPAC
functionality in any website they wanted.
I think Katrin has already said it but the great thing about Koha is that it
is all things to all people. Thousands of libraries around the world rely on
being able to customize it via configuration alone. One way or another, we'd
have to preserve that even with a Koha Core model. So you might have
Deichman::Circulation, but we'd still need a Community::Circulation which
re-implements what we already have for the people who can't afford their own
Organisation::Circulation.
I suppose what I'm saying is... I'm sure the community will welcome patches,
so long as you're able to preserve what's already there. And maybe that
means refactoring C4::Circulation into Core::Circulation and
Community::Circulation, and then Deichman can override Core::Circulation
going forward while the community maintains Core:: and Community::. I can't
imagine any objections to that.
I haven't looked at the code that Jonathan linked, but I'm guessing that you
have a separate user interface that invokes your Deichman::Circulation
module anyway, so it wouldn't affect Koha per se.
In any case, I think it's an interesting idea. I think Koha is currently a
huge monolith and could benefit from further modularization that allows it
to be easily extended. Of course, that could always fragment contributions
to Koha... so vendors just provide their own flavours of Koha and don't
contribute back to the Core, but that already happens to a degree out of
necessity. Perhaps having a separate Core would make it easier to divide up
the "patches that can be upstreamed" versus the "patches that are just
relevant locally".
Keen to hear more on this one.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
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>
[mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> ] On Behalf Of Benjamin
Rokseth
Sent: Wednesday, 11 April 2018 1:04 AM
To: koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org>
Subject: [Koha-devel] Koha Core anyone?
Community hackers,
on hackfest I got introvertly enthusiastic about the concept of a Koha Core,
and about time I shared some thoughts.
Background: Deichman (Oslo Public Library) is heavily leaning on bleeding
edge Koha development (REST, Objects, Auth, NCIP and such) and, like at
least some others, maintain a lot of local patches to tweak Koha into our
users needs. Some are probably interesting to Community, others not. Now to
keep everything in sync with Community would be amazing, but not likely to
happen anytime soon.
Great work has been done on refactoring Koha (new namespace, Koha Objects
and REST api, etc.), but we'd like to suggest one more - a Koha core.
The idea is simple: borrow from object oriented languages, java, or actually
more ruby, since we're dealing with a dynamic language, use class/module
inheritance and method overrides.
Perl has the "use parent" concept which simplifies inheritance/subclassing
and allows for nested overrides.
As an example we refactored the current circulation in Koha, since this for
us is the core functionality that we depend on and need to hook our local
quirks on top of.
An attempt to illustrate:
+------------+
| Core::Main |
+--^---------+
|
+--+----------------+
| Core::Prefs |
| Core::Exceptions | +-----------------------+
| Core::Circulation <-----+------+---| Deichman::Circulation |
| ... | | | +---^-------------------+
+-------------------+ | | |
| | |
+------------------+------+ +--------------------------+
| Core::Circulation::SIP | |Deichman::Circulation::SIP|
+------------------------------------------------------------+
| use parent qw(
| Deichman::Circulation
+----------------------+ Core::Circulation::SIP
| Core::Circulation::UI| )
+----------------------+
|
~
* Core::Main is simply an empty class that act as a parent for any child,
including Core::Circulation.
* Core::Circulation has a constructor that takes koha objects item and
library, optionally patron
and sysprefs overrides. It can have accessors such as checkout, messages
and other things needed for
intra, SIP or whatever. It has methods Checkin, Checkout and Renew,
amongst others.
* then: Deichman::Circulation::SIP in this example is a local override that
inherits from parents
Deichman::Circulation and Core::Circulation::SIP
now the beauty of this is that Deichman::Circulation::SIP can override
anything (even the constructor) without touching any of the core code, and
perl will traverse the inheritance tree until it finds the first matching
constructor and method.
Pros:
- simpler, more readable and more reusable code.
- local adaptations are easy to hande, and reusable for others
- the slight overhead of using blessed objects and inheritance is easily
gained by the fact that any
operation will only need fetching Koha objects once (item,library,patron
etc) instead of refetching
them numerous times spread across methods calls and loops
- way less db calls if done right, faster Koha
- no more C4::Context, hopefully
- systempreferences can be dramatically reduced, since most of them are
about overrides anyways
- can be done incrementally, replacing one functionality at a time
cons:
- refactoring doesnt make end users happy (but needs to be done in any
case)
- a bit of work to keep templates happy
- requires a basic understanding of oop
So to sum up: We already have a working example for circulation (though not
in production) that we can demonstrate. It reimplements basically the entire
C4::Circulation, just some small parts missing. So it can be done.
But we'd love to hear second opinions from the community! We know the fear
for breaking changes, but its neither scary or complicated to implement!
Benjamin Rokseth
Oslo Public Library
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto: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/
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto: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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180420/7b0f0def/attachment-0001.html>
More information about the Koha-devel
mailing list