[Koha-devel] Koha Core anyone?

[Katrin Fischer]

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 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/
>>