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
Hi Magnus and all, Il 11/02/2016 10:38, Magnus Enger ha scritto:
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.
I subscribe the option "one Koha to rule them all". In fact in Italy is possible that "one login DB for all libraries" and "one Italian id for Authority[like Idref from France]" will became very important. Clearly those principles are important:
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 I hope that "in time, the plugin system can be made powerful enough that it can handle some or all of the country-specific features?" Bye Zeno Tajoli -- Zeno Tajoli / SVILUPPO PRODOTTI/ - Automazione Biblioteche Email: z.tajoli@cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)
I agree completely with Magnus and Zeno! "One Koha to rule them all", where country-specific development should strive to be as general and unobtrusive as possible for the time being, and then focusing on a better/stronger plug-in system! Best regards, Andreas ____________________________________ Andreas Hedström Mace Librarian Stockholm University Library Stockholm University 106 91 Stockholm Tel: +46 (0) 8-16 49 17 www.sub.su.se ____________________________________ -----Ursprungligt meddelande----- Från: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] För Tajoli Zeno Skickat: den 11 februari 2016 10:47 Till: Magnus Enger <magnus@enger.priv.no>; koha-devel@lists.koha-community.org Ämne: Re: [Koha-devel] Country-specific forks? Hi Magnus and all, Il 11/02/2016 10:38, Magnus Enger ha scritto:
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.
I subscribe the option "one Koha to rule them all". In fact in Italy is possible that "one login DB for all libraries" and "one Italian id for Authority[like Idref from France]" will became very important. Clearly those principles are important:
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 I hope that "in time, the plugin system can be made powerful enough that it can handle some or all of the country-specific features?" Bye Zeno Tajoli -- Zeno Tajoli / SVILUPPO PRODOTTI/ - Automazione Biblioteche Email: z.tajoli@cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) _______________________________________________ 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/
+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.maurice@biblibre.com> BibLibre
Of course, we should keep Norway in our boat :) But I could understand some amazement about warnings on a Norwegian module. Maybe those calls should not be on "top level" but be handled in some nice Norwegian subclass or so? -----Oorspronkelijk bericht----- Van: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] Namens Julian Maurice Verzonden: donderdag 11 februari 2016 11:24 Aan: koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] Country-specific forks? +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.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/
Same for me: +1 to "one Koha to rule them all" +1000 to a more powerful plugin system! Marc Am 11.02.2016 um 11:24 schrieb Julian Maurice:
+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.
Dear Colleagues, For what it's worth, consider how Mozilla offers Firefox with its "market place" of extensions/plug-ins. Yes many of the extensions overlap and have duplicate features, but that just makes Firefox that much more flexible, open, and lovable (IMHO). Sure there might be neglected extensions/plug-ins for deprecated versions of Koha, but that is not new to any open source software market place such as Sourceforge, Github, Google Code, etc. I think that it would send Koha users the message that the software truly belongs to them and that they can do extreme customization with plug-ins or contribute modest patches and enhancements to a core, global-friendly Koha Master. With Firefox's success, I know that such a system is possible Thank you, Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary On Sun, Feb 14, 2016 at 3:26 PM, Katrin Fischer <Katrin.Fischer.83@web.de> wrote:
Am 11.02.2016 um 12:07 schrieb Marc Véron:
Same for me:
+1 to "one Koha to rule them all" +1000 to a more powerful plugin system!
Marc
... and same for me :)
Katrin
_______________________________________________ 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/
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@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.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/
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 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@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.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/
That sounds awesome! I'd love to see a proof on concept for that, or maybe a full patch! ; ) 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 7:14 AM, Jonathan Druart < jonathan.druart@bugs.koha-community.org> wrote:
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.
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
2016-02-11 11:47 GMT+00:00 Kyle Hall <kyle.m.hall@gmail.com>: 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@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.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/
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 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@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.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
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@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@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@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.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
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
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
) 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 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
2016-02-11 12:30 GMT+00:00 Julian Maurice <julian.maurice@biblibre.com>: patch patron DB 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/
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
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@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@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
>> 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 patron 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
_______________________________________________ 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/
-- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F
Just so I do not sound like a Norwegian-hater (which would be very hard, I can't imagine anyone hating Norwegians! ), I want to specify that my comment was not suggesting a specific fork. That would be messy. I would have thought this feature could have been generalized enough to be named something else than "Norvegian", and if something needed to be hardcoded, it could be a patch easily downloadable, maintained by the Norwegian community. (Not sure what that implies, so please use salt...:) ) But then again, I don't mind the name as much as the fact that it brought a lot with it, filled my logs, forced me to update my servers and realise that it must be "compiling" (and failing) every single time i get on those pages, thus impacting performance... Then writing an email and sounding like Norwegians are the worst :-) I hope to visit Norway one day... Philippe Blouin, Responsable du développement informatique Tél. : (888) 604-2627 philippe.blouin@inLibro.com <mailto:philippe.blouin@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> On 02/11/2016 04:38 AM, Magnus Enger wrote:
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/
+1 fror the "one Koha to rule them all" approach. Such country-specific yet country-wide needs would become occasions to consider koha functionality in a broader context, for the principle behind them is very unlikely to be unique and restricted to a single country. Good ideas and organization developments tend to resurface globally. It is bad enough that there are an open koha and a separate open-ish one, that program behaviour may be altered by the combination of OS distribution and libraries used, version-specific features and regressions. Country-specific forks quickly become dated, and would in fact deter new libraries/organizations from considering koha. Consider the analog of Microsoft making globally available English/Spanish/Chinese versions of MS-Office 2013, supplying French, German and Russian markets though with country-specific versions of MS-Office 2002/XP. Not a good move, surely. If koha aspires to be used globally, it should try and be country/language/culture agnostic. One example I may quote is character sets supported in Z39.50 target definitions. Once the need to support more than one character set is acknowledged, the "global" approach would be to make koha able to easily accommodate any language/set, not just to manually amend code in order to add a single language/set, each time an addition is requested. In general, whatever may be defined in the database - and changed by the implementor in a trial-and-error procedure - would best be kept off the code. More server resources may be thus required, this approach however leads to a more adaptable, more agile product. Hope to meet you in Salonica on May 31st :-) Manos Petridis
Salvete!
So do we want one Koha to rule them all, including country-specific features, or do we want one fork per country?
+1 to One Koha to Rule Them All, provided that Koha remain GPL as always and not under Sauron's control. ;) But seriously, a long time ago when animals could talk, I remember pointing out that it was easy to swap languages on the catalogue. This is an extremely useful feature to multilingual organisations or bodies - read Kiwis, the UN, Canadians and any other nation with more than one official language, silly nations like the US with NO official language, CKJ libraries and so on. Now if y'all are clever enough to get stuff to work in a way that lets people whittle things down appropriately through plugins, more power to you. If modules must be made, I still beg folks to break that down in terms of Library type preference sets so that there's a Koha in a Box for Small Rural Libraries, one for Large Academic Libraries, et cetera. Cheers, Brooke
I actually think a more general plugin system would both increase the attraction of new libraries and keep existing ones from wanting to fork. Being a firm believer in running the community code it is sometimes frustrating that key features might take years to ge into master. All ways that makes it easy to run standard Koha while still altering the behaviour is therefore welcome. (At the same time I'm a little bit afraid of a future where the ones with resources make their own addons since it's easier and the community codebase never gets the chance to implement good features in a generic way. A bit like "yes it's not very good, but that's why you'll also want to buy this extra discovery system that we happen to sell as well" that seems to happen in some proprietary products.) Kind regards/ Viktor Sarge Senior regional library development officer Skickat från min iPhone
11 feb. 2016 kl. 10:38 skrev Magnus Enger <magnus@enger.priv.no>:
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/
participants (17)
-
Andreas Hedström Mace -
BWS Johnson -
Christopher Davis -
Jesse -
Jonathan Druart -
Julian Maurice -
Katrin Fischer -
Kyle Hall -
Magnus Enger -
Manos PETRIDIS -
Marc Véron -
Marcel de Rooy -
Philippe Blouin -
Renvoize, Martin -
Tajoli Zeno -
Tomas Cohen Arazi -
Viktor.Sarge＠regionhalland.se