[Koha-devel] Country-specific forks?

Thu Feb 11 20:06:35 CET 2016

I think that specific dev should have been generalized as a way to sync
external sources (as we do with LDAP). A "plugin" could provide a specific
configuration/maintenance script.

2016-02-11 15:59 GMT-03:00 Jesse <pianohacker at gmail.com>:

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

-- 
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160211/459af3a6/attachment.html>