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@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@bugs.koha-community.org> wrote:
Yes, it will be a limitation. For the signatures, we will have to maintain the plugins and version them.
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@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
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
) 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@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
> 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
2016-02-11 12:30 GMT+00:00 Julian Maurice <julian.maurice@biblibre.com>: pluggable. It's patron DB libraries 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.maurice@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.maurice@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