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
Hi Benjamin, Where is the code of the "working example"? Cheers, Jonathan On Tue, 10 Apr 2018 at 12:04 Benjamin Rokseth <benjamin.rokseth@deichman.no> wrote:
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@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/
Ha, found it! https://gitlab.deichman.no/digibib/Koha/commits/circ_rewrite_master I was looking at the digibib github repo! On Tue, 10 Apr 2018 at 13:28 Jonathan Druart < jonathan.druart@bugs.koha-community.org> wrote:
Hi Benjamin,
Where is the code of the "working example"?
Cheers, Jonathan
On Tue, 10 Apr 2018 at 12:04 Benjamin Rokseth < benjamin.rokseth@deichman.no> wrote:
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@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/
Very excited by this idea. Lot's to think about. We're on board with most of it and are ready to help. Cheers, Brendan On Tue, Apr 10, 2018 at 9:30 AM, Jonathan Druart < jonathan.druart@bugs.koha-community.org> wrote:
Ha, found it! https://gitlab.deichman.no/digibib/Koha/commits/circ_rewrite_master I was looking at the digibib github repo!
On Tue, 10 Apr 2018 at 13:28 Jonathan Druart <jonathan.druart@bugs.koha- community.org> wrote:
Hi Benjamin,
Where is the code of the "working example"?
Cheers, Jonathan
On Tue, 10 Apr 2018 at 12:04 Benjamin Rokseth < benjamin.rokseth@deichman.no> wrote:
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@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@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/
-- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Office: Portland, OR - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com
Hi, and thanks for quick feedback folks. Good catch, Jonathan, we recently moved to gitlab since they integrate devops and CI build tools. The branch circ_rewrite_master is rebased against master, but havent tested properly yet, so its very WIP but you'll get the general idea. Julian,
I have some concerns about this approach. You are saying that local
adaptations are reusable for others, but I don't see how. Deichman::* will inevitably end up being highly specific. I could probably copy/paste some code, but I think we will all have to write our own MyLibrary::* stuff.
Your concern is probably sound, since it is easier to add all local adaptations to a local namespace (Deichman::*) and be done with it. What I'd suggest though is that modules are kept as atomic as possible so that anything can possibly be overridden. Its kind of the opposite of todays practise where sysprefs are scattered all over the code to adjust for local variations, at least from what I've seen in the C4::Circulation. I think it would make sense to allow for a Core Circulation that never touch sysprefs, while at the same time having a "default" or "full-blown" implementation that can do exactly what C4::Circulation does today.
I'd prefer to extend the capabilities of plugins. This way we could combine small generic plugins to answer specific needs.
Actually, I didnt realize plugins was more than tools to extend reports, kind of a stepwise db tooling. At least the examples I saw was just CGI templates that must be aactively run to modify database. And they seemed based on CGI templating which doesnt help us much. In any case, to plug into something central, such as Circulation, the circulation modules would need to be rewritten.
But you also say that you reimplemented all the circulation stuff, and that it was not complicated, so I'm curious :) Show us the code!
WIP for sure, but as Jonathan found out, here is a single commit on top of master https://gitlab.deichman.no/digibib/Koha/commits/circ_rewrite_master I see now we use a local caching trick with method attributes (PureFunctions) that is not included, so I will have to remove that or it will not work at present. But if theres some interest, I will open a bug and commit so people can test it. I will try to commit at least to make circulation work as in a standard installation. Benjamin ________________________________ Fra: Brendan Gallagher <info@bywatersolutions.com> Sendt: 10. april 2018 21:34 Til: Jonathan Druart Kopi: Benjamin Rokseth; koha-devel@lists.koha-community.org Emne: Re: [Koha-devel] Koha Core anyone? Very excited by this idea. Lot's to think about. We're on board with most of it and are ready to help. Cheers, Brendan On Tue, Apr 10, 2018 at 9:30 AM, Jonathan Druart <jonathan.druart@bugs.koha-community.org<mailto:jonathan.druart@bugs.koha-community.org>> wrote: Ha, found it! https://gitlab.deichman.no/digibib/Koha/commits/circ_rewrite_master I was looking at the digibib github repo! On Tue, 10 Apr 2018 at 13:28 Jonathan Druart <jonathan.druart@bugs.koha-community.org<mailto:jonathan.druart@bugs.koha-community.org>> wrote: Hi Benjamin, Where is the code of the "working example"? Cheers, Jonathan On Tue, 10 Apr 2018 at 12:04 Benjamin Rokseth <benjamin.rokseth@deichman.no<mailto:benjamin.rokseth@deichman.no>> wrote: 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@lists.koha-community.org<mailto: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/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto: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/ -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Office: Portland, OR - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com<mailto:info@bywatersolutions.com>
Hi Benjamin, I have some concerns about this approach. You are saying that local adaptations are reusable for others, but I don't see how. Deichman::* will inevitably end up being highly specific. I could probably copy/paste some code, but I think we will all have to write our own MyLibrary::* stuff. I'd prefer to extend the capabilities of plugins. This way we could combine small generic plugins to answer specific needs. But you also say that you reimplemented all the circulation stuff, and that it was not complicated, so I'm curious :) Show us the code! Le 10/04/2018 à 17:04, Benjamin Rokseth a écrit :
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@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/
-- Julian Maurice <julian.maurice@biblibre.com> BibLibre
Hi all, I am a bit worried that we will end up building a system for power users, that have the option to extend Koha with local development to make it fit. Let's also keep the users in mind, that don't have that option and need a system that is flexible by configuration. There is also the question what will make it into Core and how to handle changes that might effect dependent modules. How much of the local adaptations will be submitted to Koha proper and who will maintain them? We have quite a lot of ongoing projects at the moment, but finding the resources to keep them moving has been proven hard. Katrin On 10.04.2018 18:28, Julian Maurice wrote:
Hi Benjamin,
I have some concerns about this approach. You are saying that local adaptations are reusable for others, but I don't see how. Deichman::* will inevitably end up being highly specific. I could probably copy/paste some code, but I think we will all have to write our own MyLibrary::* stuff.
I'd prefer to extend the capabilities of plugins. This way we could combine small generic plugins to answer specific needs.
But you also say that you reimplemented all the circulation stuff, and that it was not complicated, so I'm curious :) Show us the code!
Le 10/04/2018 à 17:04, Benjamin Rokseth a écrit :
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@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/
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@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Benjamin Rokseth Sent: Wednesday, 11 April 2018 1:04 AM To: koha-devel@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@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/
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@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@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Benjamin Rokseth Sent: Wednesday, 11 April 2018 1:04 AM To: koha-devel@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@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@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/
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.... 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@gmail.com] Sent: Friday, 20 April 2018 3:38 AM To: David Cook <dcook@prosentient.com.au> Cc: Benjamin Rokseth <benjamin.rokseth@deichman.no>; Koha Devel <koha-devel@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@prosentient.com.au <mailto:dcook@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@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> [mailto:koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> ] On Behalf Of Benjamin Rokseth Sent: Wednesday, 11 April 2018 1:04 AM To: koha-devel@lists.koha-community.org <mailto:koha-devel@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@lists.koha-community.org <mailto: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/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/
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@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of David Cook Sent: Friday, 20 April 2018 9:29 AM To: 'Kyle Hall' <kyle.m.hall@gmail.com> Cc: 'Koha Devel' <koha-devel@lists.koha-community.org>; 'Benjamin Rokseth' <benjamin.rokseth@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.... 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@gmail.com] Sent: Friday, 20 April 2018 3:38 AM To: David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > Cc: Benjamin Rokseth <benjamin.rokseth@deichman.no <mailto:benjamin.rokseth@deichman.no> >; Koha Devel <koha-devel@lists.koha-community.org <mailto:koha-devel@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@prosentient.com.au <mailto:dcook@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@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> [mailto:koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> ] On Behalf Of Benjamin Rokseth Sent: Wednesday, 11 April 2018 1:04 AM To: koha-devel@lists.koha-community.org <mailto:koha-devel@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@lists.koha-community.org <mailto: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/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/
I think multi-tenancy is definitely matters for support providers as an efficient deployment option. I'd love to get Tomas's thoughts on the matter as he's been interested in both. 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 Thu, Apr 19, 2018 at 8:24 PM, David Cook <dcook@prosentient.com.au> wrote:
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 <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW&entry=gmail&source=g>
Ultimo, NSW <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW&entry=gmail&source=g> 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *David Cook *Sent:* Friday, 20 April 2018 9:29 AM *To:* 'Kyle Hall' <kyle.m.hall@gmail.com> *Cc:* 'Koha Devel' <koha-devel@lists.koha-community.org>; 'Benjamin Rokseth' <benjamin.rokseth@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 <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW&entry=gmail&source=g>
Ultimo, NSW <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW&entry=gmail&source=g> 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:* Kyle Hall [mailto:kyle.m.hall@gmail.com <kyle.m.hall@gmail.com>] *Sent:* Friday, 20 April 2018 3:38 AM *To:* David Cook <dcook@prosentient.com.au> *Cc:* Benjamin Rokseth <benjamin.rokseth@deichman.no>; Koha Devel < koha-devel@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
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@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 <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW&entry=gmail&source=g> Ultimo, NSW <https://maps.google.com/?q=72/330+Wattle+St+Ultimo,+NSW&entry=gmail&source=g> 2007 Australia
Office: 02 9212 0899 Direct: 02 8005 0595
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Benjamin Rokseth Sent: Wednesday, 11 April 2018 1:04 AM To: koha-devel@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@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@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/
participants (7)
-
Benjamin Rokseth -
Brendan Gallagher -
David Cook -
Jonathan Druart -
Julian Maurice -
Katrin Fischer -
Kyle Hall