RM for 3.4 Proposal

From Koha Wiki

Jump to: navigation, search
Home > Koha Versions > 3.4



Koha has had 4 major feature releases in a row now, 2.0, 2.2, 3.0 and 3.2. These all introduced a lot of great new features but they also substantially increased the code base. I propose that 3.4 try to address some of the need for refactoring and performance related code changes, while still allowing for new features


Memoize and Memcached

Some work has already been done using these technologies to increase the performance of Koha but caching the results of much used subroutines.


The easiest and most effective performance boost for Koha is to make it mod_perl2 safe so that if users want to use mod_perl2 it can be used. Making Koha 3.4 safe for use with mod_perl2 is a major goal.

Supporting Apache::PerlRun is certainly doable, but support for Apache::Registry will take rather more code cleanup. Which are you proposing for 3.4? --- //Galen Charlton 2010/02/10 06:34//


For the most part this module does it job, but it is overly complicated and hard to maintain and change. Refactoring this a major goal.

Circulation performance

XML out of circulation code

One of the big bottlenecks in circulation at present is the constant parsing and writing of XML. Shifting the data needed for circ out of the xml columns and shifting the processing of xml out of the circulation code will speed it up immensely. Henri Damien Laurent has done some work in this area, I will be drawing heavily on his ideas.

It's more general than getting XML out of the circulation code as such - the issue is, more broadly, embedding item data in the bib MARC and MARCXML. Getting it out will also improve performance during cataloging, particularly in the case of serials. It will also resolve an issue where OPAC and staff bib details display fails if a bib has more than a few hundred items attached to it. --- //Galen Charlton 2010/02/10 06:30//


Adding AJAX support that fails gracefully is another good potential performance boost


Finishing the debian packaging for 3.4 is a major goal. If packages can be created for other distributions that would be great also

Template Toolkit

HTML::Template::Pro has served us well for few years but we are running into limitations with it. Template::Toolkit is under much more active development, is more feature rich and allows for much easier to maintain and translate templates This is a major goal for 3.4

Database Abstraction

I would like 3.4 to be installable on both mysql and postgresql with equal ease

New features

Features described at RFCs for Koha 3.4

Potential timing

I would like 3.4 to be a short cycle release, perhaps 6 months long, so that we can get our tidying and performance boosts in short order. And get back to a bigger feature release.

It's going to be ambitious to do much in the way of any feature work with all of the packaging and refactoring going on *and* add support for Pg *and* (especially) change the templating system. 6 months is a good goal, but I think we're going to have to prioritize the architectural improvements and defer some for 3.6 if we're to meet 6 months. --- //Galen Charlton 2010/02/10 06:32//

Personal tools