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.renvo...@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.dru...@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.maur...@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.h...@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.maur...@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@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.maur...@biblibre.com> >> >>>> BibLibre >> >>>> _______________________________________________ >> >>>> 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/ >> > >> > >> > -- >> > Julian Maurice <julian.maur...@biblibre.com> >> > BibLibre >> _______________________________________________ >> 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/ > -- Jesse Weaver
_______________________________________________ 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/