Re: [Koha-devel] RFC: proposing change to Koha's plugins system
At 10:16 PM 8/21/2014 +0000, Indranil Das Gupta wrote:
Hi all,
I've been trying to use the KPZ structure in some of my projects. In general, I've found it rather useful, with a few modifications.
I would like to propose the following changes as http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12805
lets have your feedback on this.
With a view of maintaining core stability for Koha, all 'enhancements' (e.g. plug-ins) should be optional and not affect speed, size and cpu cycles of basic functionality. I think that this is what you are proposing... if I'm mistaken, please advise. I've been relatively quiet for some time about my intrinsic belief that a two year cycle of updating Koha (along the same 2-year lines of most OS's) should be the norm. "If it ain't broke, don't fix it." Enhancements (not security updates) should be for the end-user to decide upon, and most libraries do not have the personnel | time | budget to get involved every couple of months. I recognize that the paid consultants may have an interest -- and I have absolutely nothing against that; without them a huge amount of "Koha devel" would not take place. However, we are getting ready to upgrade our servers from 2012 to 2014 standards, and I've been looking at Koha 3.14 and 3.16. We are *not* a lending library -- just a big research centre -- and quite frankly I can find no totally compelling reason to upgrade from 3.8 (handheld browsers might be the exception.) Again, if I'm mistaken, please advise. Please don't misunderstand me. I'm all in favour of "improvments", but when a quick analysis of one of my OPAC pages come up with: Combine external CSS (6) Combine external JavaScript (11) Leverage browser caching (23) Leverage proxy caching (5) Minimize cookie size Serve static content from a cookieless domain (11) Specify image dimensions (1) Optimize the order of styles and scripts (2) Remove unused CSS rules (1335) Use normal CSS property names instead of vendor-prefixed ones (3) it's probably better to look at the 1,335 "unused CSS rules"... (bootstrap? doesn't do away with yahoo? does zebra depend on yahoo?) End rant. I promote Koha wherever I can, but in my job I've got to stay practical. Over the last four years we've put in place a marvelous OPAC meeting our users requirements. Please keep up the good work, but please also maintain core stability. Compare with Debian (lenny, squeeze, wheezy, 2 year cycle); Ubuntu (lynx, pangolin, tahr, 2 year cycle); Apache (2.2 ==> 2.4, eight/ten? year cycle); MySQL (fairly minor in the 5. series, no urgency); Perl (ditto); etc... Best -- Paul
On 22/08/14 12:32, Paul A wrote:
At 10:16 PM 8/21/2014 +0000, Indranil Das Gupta wrote:
Hi all,
I've been trying to use the KPZ structure in some of my projects. In general, I've found it rather useful, with a few modifications.
End rant. I promote Koha wherever I can, but in my job I've got to stay practical. Over the last four years we've put in place a marvelous OPAC meeting our users requirements. Please keep up the good work, but please also maintain core stability. Compare with Debian (lenny, squeeze, wheezy, 2 year cycle); Ubuntu (lynx, pangolin, tahr, 2 year cycle); Apache (2.2 ==> 2.4, eight/ten? year cycle); MySQL (fairly minor in the 5. series, no urgency); Perl (ditto); etc...
If you and others are willing to pay people to do this, it will get done. That's what it boils down. 4 years of something ... maybe time to contribute back? Chris
Paul A schreef op do 21-08-2014 om 20:32 [-0400]:
With a view of maintaining core stability for Koha, all 'enhancements' (e.g. plug-ins) should be optional and not affect speed, size and cpu cycles of basic functionality. I think that this is what you are proposing... if I'm mistaken, please advise.
Nothing in what Indranil is talking about is at all related to any of that, in the slightest. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
Please don't misunderstand me. I'm all in favour of "improvments", but I'm trying to understand you. You come across as somewhat saracstic, but I hope I'm wrong.
The chrome audit analysis you cite is not that bad. If you run it even on google search page you will also find ~1000 unused css rules. Im not saying these kind of micro-optiizations not are worthwhile, but it's likely to have a very minor impact on Koha's performance as a whole. Some nanoseconds maybe. As for long vs short release cycles - I prefer frequent releases. Keep up the good work, everyone:) Best regards Petter Goksøyr Åsen Deichmanske bibliotek / Oslo Public Library ________________________________________ Fra: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] på vegne av Paul A [paul.a@navalmarinearchive.com] Sendt: 22. august 2014 02:32 Til: koha-devel@lists.koha-community.org Emne: Re: [Koha-devel] RFC: proposing change to Koha's plugins system At 10:16 PM 8/21/2014 +0000, Indranil Das Gupta wrote:
Hi all,
I've been trying to use the KPZ structure in some of my projects. In general, I've found it rather useful, with a few modifications.
I would like to propose the following changes as http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12805
lets have your feedback on this.
With a view of maintaining core stability for Koha, all 'enhancements' (e.g. plug-ins) should be optional and not affect speed, size and cpu cycles of basic functionality. I think that this is what you are proposing... if I'm mistaken, please advise. I've been relatively quiet for some time about my intrinsic belief that a two year cycle of updating Koha (along the same 2-year lines of most OS's) should be the norm. "If it ain't broke, don't fix it." Enhancements (not security updates) should be for the end-user to decide upon, and most libraries do not have the personnel | time | budget to get involved every couple of months. I recognize that the paid consultants may have an interest -- and I have absolutely nothing against that; without them a huge amount of "Koha devel" would not take place. However, we are getting ready to upgrade our servers from 2012 to 2014 standards, and I've been looking at Koha 3.14 and 3.16. We are *not* a lending library -- just a big research centre -- and quite frankly I can find no totally compelling reason to upgrade from 3.8 (handheld browsers might be the exception.) Again, if I'm mistaken, please advise. Please don't misunderstand me. I'm all in favour of "improvments", but when a quick analysis of one of my OPAC pages come up with: Combine external CSS (6) Combine external JavaScript (11) Leverage browser caching (23) Leverage proxy caching (5) Minimize cookie size Serve static content from a cookieless domain (11) Specify image dimensions (1) Optimize the order of styles and scripts (2) Remove unused CSS rules (1335) Use normal CSS property names instead of vendor-prefixed ones (3) it's probably better to look at the 1,335 "unused CSS rules"... (bootstrap? doesn't do away with yahoo? does zebra depend on yahoo?) End rant. I promote Koha wherever I can, but in my job I've got to stay practical. Over the last four years we've put in place a marvelous OPAC meeting our users requirements. Please keep up the good work, but please also maintain core stability. Compare with Debian (lenny, squeeze, wheezy, 2 year cycle); Ubuntu (lynx, pangolin, tahr, 2 year cycle); Apache (2.2 ==> 2.4, eight/ten? year cycle); MySQL (fairly minor in the 5. series, no urgency); Perl (ditto); etc... Best -- Paul _______________________________________________ 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 (4)
-
Chris Cormack -
Paul A -
Petter Goksøyr Åsen -
Robin Sheat