[Koha-devel] Country-specific forks?

Thu Feb 11 19:59:17 CET 2016

Magnus, as the original dev of the NorwegianPatronDB feature, it would be
useful to know what hooks you would have needed to implement this as a
plugin (without having to completely override/monkey patch subroutines).

2016-02-11 11:50 GMT-07:00 Renvoize, Martin <martin.renvoize at ptfs-europe.com
>:

> Hmm, I'm wary of monkey patch like stuff like that... Though it certainly
> has its place.  Agree in general that we need to be more pluggable.. Though
> when I suggested that the Norwegian stuff should have extended the plugin
> system in core then been a plugin I was met with a fair bit of opposition
> at the time.
> On 11 Feb 2016 12:38 pm, "Jonathan Druart" <
> jonathan.druart at bugs.koha-community.org> wrote:
>
>> Yes, it will be a limitation.
>> For the signatures, we will have to maintain the plugins and version them.
>>
>> 2016-02-11 12:30 GMT+00:00 Julian Maurice <julian.maurice at biblibre.com>:
>> > Problems that quickly come to mind with this solution:
>> > * It will prevent 2 different plugins to redefine the same subroutine
>> > * If the subroutine "signature" change, the compatibility with existing
>> > plugins will be broken
>> >
>> >
>> > Le 11/02/2016 13:14, Jonathan Druart a écrit :
>> >> A really easy solution to implement would be to watch a directory (say
>> >> plugins) during the very end of the compilation time.
>> >> Using something like Sub::Override
>> >> (http://search.cpan.org/~ovid/Sub-Override-0.09/lib/Sub/Override.pm)
>> >> would allow the plugin to redefine behaviors.
>> >>
>> >> 2016-02-11 11:47 GMT+00:00 Kyle Hall <kyle.m.hall at gmail.com>:
>> >>> Totally agree with this. All we need to do is imagine where we want
>> Koha to
>> >>> be pluggable! So far we have the ability create Report/Tool plugins,
>> >>> arbitrary file to MARC conversion plugins, and I also have submitted
>> a patch
>> >>> to make EDIFACT pluggable ( once it gets it ). The first step is to
>> know
>> >>> what behavior needs to be modified, then make that behavior
>> pluggable. It's
>> >>> almost a chicken or the egg issue. I suppose what we need to do is
>> watch for
>> >>> new patches for very region specific features ( such as Norwegian
>> patron DB
>> >>> ) and suggest a path to plug-ability rather pushing the code itself
>> into
>> >>> Koha.
>> >>>
>> >>> 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 )
>> >>> Mill Run Technology Solutions ( http://millruntech.com )
>> >>>
>> >>> On Thu, Feb 11, 2016 at 5:24 AM, Julian Maurice
>> >>> <julian.maurice at biblibre.com> wrote:
>> >>>>
>> >>>> +1 to "one Koha to rule them all"
>> >>>> +1000 to a more powerful plugin system!
>> >>>> Having a plugin system to build custom tools and reports is great,
>> but I
>> >>>> think we could (and should) go further.
>> >>>>
>> >>>> Le 11/02/2016 10:38, Magnus Enger a écrit :
>> >>>>> Dear Community!
>> >>>>>
>> >>>>> A quote from another thread on koha-devel:
>> >>>>>
>> >>>>> "I look at the code, and beside wondering why that custom feature
>> >>>>> [Norwegian patron DB] is so profoundly imbricated into master Koha,
>> I
>> >>>>> was wondering what is not working."
>> >>>>>
>> >>>>> I think this raises an interesting question. Should we let features
>> >>>>> into Koha that are only of interest to libraries in one or a small
>> >>>>> number of countries? Or should we confine those features to
>> >>>>> country-specific forks?
>> >>>>>
>> >>>>> The quote above implies (I think) that support for the Norwegian
>> >>>>> patron DB should be in a country-specific fork.
>> >>>>>
>> >>>>> On the other hand, the project implementing Koha for public
>> libraries
>> >>>>> in Turkey has been criticized for not integrating their
>> customizations
>> >>>>> into Koha. To which someone replied that the customizations were not
>> >>>>> of much interest to libraries outside Turkey.
>> >>>>>
>> >>>>> So do we want one Koha to rule them all, including country-specific
>> >>>>> features, or do we want one fork per country?
>> >>>>>
>> >>>>> Personally, I prefer the former. In the case of the Norwegian patron
>> >>>>> DB, that is one of the 2-3 "must have" features that all Norwegian
>> >>>>> public libraries will be looking for when they are choosing between
>> >>>>> Koha or some proprietary system. Should we be telling them "Nope,
>> you
>> >>>>> can't use the real Koha, but you can use this fork over here"? That
>> >>>>> will not increase their confidence in choosing Koha, I suspect.
>> >>>>>
>> >>>>> That said, I do think some principles should be applied:
>> >>>>>
>> >>>>> - Strive to make even the country specific features as general as
>> >>>>> possible, so that others can use them as starting points for similar
>> >>>>> features.
>> >>>>>
>> >>>>> - Strive to make the features as unobtrusive as possible.
>> >>>>>
>> >>>>> And maybe, in time, the plugin system can be made powerful enough
>> that
>> >>>>> it can handle some or all of the country-specific features?
>> >>>>>
>> >>>>> Thoughts?
>> >>>>>
>> >>>>> Best regards,
>> >>>>> Magnus Enger
>> >>>>> Libriotech
>> >>>>> _______________________________________________
>> >>>>> 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/
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Julian Maurice <julian.maurice at biblibre.com>
>> >>>> BibLibre
>> >>>> _______________________________________________
>> >>>> Koha-devel mailing list
>> >>>> Koha-devel at lists.koha-community.org
>> >>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> >>>> website : http://www.koha-community.org/
>> >>>> git : http://git.koha-community.org/
>> >>>> bugs : http://bugs.koha-community.org/
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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/
>> >
>> >
>> > --
>> > Julian Maurice <julian.maurice at biblibre.com>
>> > BibLibre
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>
>
> _______________________________________________
> 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/
>

-- 
Jesse Weaver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160211/a4123fee/attachment.html>