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/
