<div dir="ltr">That sounds awesome! I'd love to see a proof on concept for that, or maybe a full patch! ; )</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><a href="http://www.kylehall.info" target="_blank">http://www.kylehall.info</a><br>ByWater Solutions ( <a href="http://bywatersolutions.com" target="_blank">http://bywatersolutions.com</a> )<br>Meadville Public Library ( <a href="http://www.meadvillelibrary.org" target="_blank">http://www.meadvillelibrary.org</a> )<br>Crawford County Federated Library System ( <a href="http://www.ccfls.org" target="_blank">http://www.ccfls.org</a> )<br>Mill Run Technology Solutions ( <a href="http://millruntech.com" target="_blank">http://millruntech.com</a> )<br></div></div>
<br><div class="gmail_quote">On Thu, Feb 11, 2016 at 7:14 AM, Jonathan Druart <span dir="ltr"><<a href="mailto:jonathan.druart@bugs.koha-community.org" target="_blank">jonathan.druart@bugs.koha-community.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A really easy solution to implement would be to watch a directory (say<br>
plugins) during the very end of the compilation time.<br>
Using something like Sub::Override<br>
(<a href="http://search.cpan.org/~ovid/Sub-Override-0.09/lib/Sub/Override.pm" rel="noreferrer" target="_blank">http://search.cpan.org/~ovid/Sub-Override-0.09/lib/Sub/Override.pm</a>)<br>
would allow the plugin to redefine behaviors.<br>
<div class="HOEnZb"><div class="h5"><br>
2016-02-11 11:47 GMT+00:00 Kyle Hall <<a href="mailto:kyle.m.hall@gmail.com">kyle.m.hall@gmail.com</a>>:<br>
> Totally agree with this. All we need to do is imagine where we want Koha to<br>
> be pluggable! So far we have the ability create Report/Tool plugins,<br>
> arbitrary file to MARC conversion plugins, and I also have submitted a patch<br>
> to make EDIFACT pluggable ( once it gets it ). The first step is to know<br>
> what behavior needs to be modified, then make that behavior pluggable. It's<br>
> almost a chicken or the egg issue. I suppose what we need to do is watch for<br>
> new patches for very region specific features ( such as Norwegian patron DB<br>
> ) and suggest a path to plug-ability rather pushing the code itself into<br>
> Koha.<br>
><br>
> Kyle<br>
><br>
> <a href="http://www.kylehall.info" rel="noreferrer" target="_blank">http://www.kylehall.info</a><br>
> ByWater Solutions ( <a href="http://bywatersolutions.com" rel="noreferrer" target="_blank">http://bywatersolutions.com</a> )<br>
> Meadville Public Library ( <a href="http://www.meadvillelibrary.org" rel="noreferrer" target="_blank">http://www.meadvillelibrary.org</a> )<br>
> Crawford County Federated Library System ( <a href="http://www.ccfls.org" rel="noreferrer" target="_blank">http://www.ccfls.org</a> )<br>
> Mill Run Technology Solutions ( <a href="http://millruntech.com" rel="noreferrer" target="_blank">http://millruntech.com</a> )<br>
><br>
> On Thu, Feb 11, 2016 at 5:24 AM, Julian Maurice<br>
> <<a href="mailto:julian.maurice@biblibre.com">julian.maurice@biblibre.com</a>> wrote:<br>
>><br>
>> +1 to "one Koha to rule them all"<br>
>> +1000 to a more powerful plugin system!<br>
>> Having a plugin system to build custom tools and reports is great, but I<br>
>> think we could (and should) go further.<br>
>><br>
>> Le 11/02/2016 10:38, Magnus Enger a écrit :<br>
>> > Dear Community!<br>
>> ><br>
>> > A quote from another thread on koha-devel:<br>
>> ><br>
>> > "I look at the code, and beside wondering why that custom feature<br>
>> > [Norwegian patron DB] is so profoundly imbricated into master Koha, I<br>
>> > was wondering what is not working."<br>
>> ><br>
>> > I think this raises an interesting question. Should we let features<br>
>> > into Koha that are only of interest to libraries in one or a small<br>
>> > number of countries? Or should we confine those features to<br>
>> > country-specific forks?<br>
>> ><br>
>> > The quote above implies (I think) that support for the Norwegian<br>
>> > patron DB should be in a country-specific fork.<br>
>> ><br>
>> > On the other hand, the project implementing Koha for public libraries<br>
>> > in Turkey has been criticized for not integrating their customizations<br>
>> > into Koha. To which someone replied that the customizations were not<br>
>> > of much interest to libraries outside Turkey.<br>
>> ><br>
>> > So do we want one Koha to rule them all, including country-specific<br>
>> > features, or do we want one fork per country?<br>
>> ><br>
>> > Personally, I prefer the former. In the case of the Norwegian patron<br>
>> > DB, that is one of the 2-3 "must have" features that all Norwegian<br>
>> > public libraries will be looking for when they are choosing between<br>
>> > Koha or some proprietary system. Should we be telling them "Nope, you<br>
>> > can't use the real Koha, but you can use this fork over here"? That<br>
>> > will not increase their confidence in choosing Koha, I suspect.<br>
>> ><br>
>> > That said, I do think some principles should be applied:<br>
>> ><br>
>> > - Strive to make even the country specific features as general as<br>
>> > possible, so that others can use them as starting points for similar<br>
>> > features.<br>
>> ><br>
>> > - Strive to make the features as unobtrusive as possible.<br>
>> ><br>
>> > And maybe, in time, the plugin system can be made powerful enough that<br>
>> > it can handle some or all of the country-specific features?<br>
>> ><br>
>> > Thoughts?<br>
>> ><br>
>> > Best regards,<br>
>> > Magnus Enger<br>
>> > Libriotech<br>
>> > _______________________________________________<br>
>> > Koha-devel mailing list<br>
>> > <a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a><br>
>> > <a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" rel="noreferrer" target="_blank">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
>> > website : <a href="http://www.koha-community.org/" rel="noreferrer" target="_blank">http://www.koha-community.org/</a><br>
>> > git : <a href="http://git.koha-community.org/" rel="noreferrer" target="_blank">http://git.koha-community.org/</a><br>
>> > bugs : <a href="http://bugs.koha-community.org/" rel="noreferrer" target="_blank">http://bugs.koha-community.org/</a><br>
>> ><br>
>><br>
>><br>
>> --<br>
>> Julian Maurice <<a href="mailto:julian.maurice@biblibre.com">julian.maurice@biblibre.com</a>><br>
>> BibLibre<br>
>> _______________________________________________<br>
>> Koha-devel mailing list<br>
>> <a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a><br>
>> <a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" rel="noreferrer" target="_blank">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
>> website : <a href="http://www.koha-community.org/" rel="noreferrer" target="_blank">http://www.koha-community.org/</a><br>
>> git : <a href="http://git.koha-community.org/" rel="noreferrer" target="_blank">http://git.koha-community.org/</a><br>
>> bugs : <a href="http://bugs.koha-community.org/" rel="noreferrer" target="_blank">http://bugs.koha-community.org/</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Koha-devel mailing list<br>
> <a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a><br>
> <a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" rel="noreferrer" target="_blank">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
> website : <a href="http://www.koha-community.org/" rel="noreferrer" target="_blank">http://www.koha-community.org/</a><br>
> git : <a href="http://git.koha-community.org/" rel="noreferrer" target="_blank">http://git.koha-community.org/</a><br>
> bugs : <a href="http://bugs.koha-community.org/" rel="noreferrer" target="_blank">http://bugs.koha-community.org/</a><br>
</div></div></blockquote></div><br></div>