April 2012 - Koha-devel - lists.koha-community.org

Kohacon12 June 9-11 hackfest
by Frédéric Demians 13 Apr '12

13 Apr '12

Hello, Is there already a program for Edinburgh June 9-11 hackfest? Who will attend? What will be discussed or done? Is some preparation/coordination required? Kind regards, -- Frédéric DEMIANS http://www.tamil.fr/u/fdemians.html

3 2

Bug 5617 - fix-perl-path.pl misses some files - UPDATE
by Bernardo Gonzalez Kriegel 13 Apr '12

13 Apr '12

On a clean install from master (and other versions), the files at the bottom are not updated by fix-perl-path.pl In a case as mine (Centos 5.6, native perl 5.8.8, perl 5.14.1 on /usr/local) this gives a system unusable because you can't change system preferences. Unless of course you fix all files by hand. I think that deserves increase its severity (currently is LOW) Perhaps adding ".pl" to some of these files (and fixing the references) could help to partially solve the problem. [master install] bin/maintenance/borrowers-force-messaging-defaults bin/admin/koha-preferences intranet/cgi-bin/installer/data/mysql/atomicupdate/bug_7284_authority_linking_pt2 (shebang "#! /usr/bin/perl", with space) intranet/cgi-bin/installer/data/mysql/atomicupdate/bug_7284_authority_linking_pt1 (shebang "#! /usr/bin/perl", with space) intranet/cgi-bin/reports/issues_by_borrower_category.plugin intranet/cgi-bin/reports/itemtypes.plugin intranet/cgi-bin/acqui/pdfformat/layout2pages.pm intranet/cgi-bin/acqui/pdfformat/layout3pages.pm intranet/cgi-bin/svc/authentication intranet/cgi-bin/svc/new_bib intranet/cgi-bin/svc/bib_profile intranet/cgi-bin/svc/import_bib intranet/cgi-bin/svc/config/systempreferences intranet/cgi-bin/svc/bib lib/C4/ShelfBrowser.pm misc/translator/translate opac/cgi-bin/opac/unapi [Koha 3.6.4] bin/maintenance/borrowers-force-messaging-defaults bin/admin/koha-preferences intranet/cgi-bin/reports/issues_by_borrower_category.plugin intranet/cgi-bin/reports/itemtypes.plugin intranet/cgi-bin/acqui/pdfformat/layout2pages.pm intranet/cgi-bin/acqui/pdfformat/layout3pages.pm intranet/cgi-bin/svc/authentication intranet/cgi-bin/svc/new_bib intranet/cgi-bin/svc/bib_profile intranet/cgi-bin/svc/config/systempreferences intranet/cgi-bin/svc/bib lib/C4/ShelfBrowser.pm misc/translator/translate opac/cgi-bin/opac/unapi [Koha 3.4.7] bin/maintenance/borrowers-force-messaging-defaults bin/admin/koha-preferences intranet/cgi-bin/reports/issues_by_borrower_category.plugin intranet/cgi-bin/reports/itemtypes.plugin intranet/cgi-bin/acqui/pdfformat/layout2pages.pm intranet/cgi-bin/acqui/pdfformat/layout3pages.pm intranet/cgi-bin/svc/authentication intranet/cgi-bin/svc/new_bib intranet/cgi-bin/svc/bib_profile intranet/cgi-bin/svc/config/systempreferences intranet/cgi-bin/svc/bib lib/C4/ShelfBrowser.pm misc/translator/translate opac/cgi-bin/opac/unapi Bernardo -- Bernardo Gonzalez Kriegel bgkriegel(a)gmail.com

1 0

SVC templates
by Ian Walls 11 Apr '12

11 Apr '12

Right now, the few web services we have all create their XML output using XML::Simple. This is not the fastest parser in the world, so I've been looking to minimize/remove it's usage. Looking at it in /svc got me thinking: perhaps we should be using T:T to generate our web services output instead. This would have all the advantages of T:T, and allow us to reuse common portions text. I think the templates would live in koha-tmpl/svc-tmpl/prog/en. From there, we could break down by output language (XML, JSON, etc), so our web services could be fully customizable in terms of output format (without having to reinvent the script, or provide long nasty if/elsif conditionals). If we put this in place now for the few /svc scripts we have, it would be a good test for the practicality of this, and if it works, could be a practice to continue forward (with several working examples). Thoughts? -Ian

2 3

combining and minification of javascript and css
by Dobrica Pavlinusic 08 Apr '12

08 Apr '12

I would like to address this one as part of performance work. We have existing bug for this, but I'm sending also this to list to get wider feedback. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1918 I found https://github.com/jshirley/Plack-Middleware-ComboLoader which got me pushed in right direction, but in the end I decided to implement Koha::Template::Plugin::Combine because it turned out that it's easier if we can use combining and minification together. Changes are available at: https://github.com/dpavlin/Koha/compare/dpavlin:plack...dpavlin:bug_1918-co… Minification alone doesn't buy us much: OPAC search: minify js 334974 -> 311553 93.01% minify css 148277 -> 133128 89.78% intranet search: minify js 382102 -> 362172 94.78% minify css 134754 -> 123771 91.85% But combining JS and CSS files together saves us round-trips to server: OPAC 32 -> 20 requests intranet 27 -> 13 requests I would love to hear your feedback on this. -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

3 2

RFC: Koha::Persistent - for plack and general performance
by Dobrica Pavlinusic 07 Apr '12

07 Apr '12

I would like to propose new module which would keep track of all persistant values for rest of Koha code. We are currently using following caching strategies: 1. our $cache variables 2. memoize (in-memory) 3. memoize_memcache (in memcache only) As opposed to C4::Cache* which never got implemented in all code, I propose new Koha::Persistant[1] module which provides methods for caching designed in such a way to reduce code size in modules which use it, see [2] for authorised_value and [3] for marc_subfield_structure 1: https://github.com/dpavlin/Koha/blob/plack/Koha/Persistant.pm 2: https://github.com/dpavlin/Koha/commit/6cd524f99b1bbc03eb1ad7110b0b97016569… 3: https://github.com/dpavlin/Koha/commit/70a414d93bd0ae309e9d6097ea87a17e3341… I implemented just two function to see if this approach makes sense. I started with DBI Profile to track down same or similar queries and try to make nice API which satisfies requirements above. It also provides $Koha::persistant::stats which can be used to track hit/miss ratio of cache so we can easily evaluate caching impact. There is even Plack development panel, see "Persistant" at 1:01-1:30 http://blog.rot13.org/koha/koha-plack-debug.ogv Koha::Persistant should also include invalidation functions for all structures which it addresses, so they can be inserted in corresponding places to provide correct values when changing data directly in database. This will be done for existing functions before I submit it to Koha to keep everything clean from the start. It would also provide memoize function, which would replace memoize_memcahe and provide in-memory caching together with memcache, but still cache in memory if memcache isn't available. As shown in http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7879 we do get performance benefit from it, since our code is using MySQL query cache a lot which means we are quering for same data over and over again, see: http://wiki.koha-community.org/wiki/Performance#MySQL_tuning In first phase, I would propose to reset in-memory cache and memoize functions on each request to be consistant with CGI implementation and side-step caching bugs which we see with plack right now. This style of implementation will require large patches which touch many different places of code at same time. I think that 3.10 relese cycle is good way to introduce this changes, but I would need commitment from developers to Sign-off and QA patches fast, since those changes will be hard to keep up with development. p.s. I will create RFC wiki page after discussion, but I would really need some response before continuing down this path. -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

5 12

Kohacon12 - Sponsorship now open!
by MJ Ray 06 Apr '12

06 Apr '12

Hi All I'm delighted to send this mail (on behalf of the organising team) to let people know we are now accepting general sponsorships for Kohacon12, by bank transfer or paypal/card. http://koha-community.org/kohacon12/sponsoring-kohacon12/ As you probably all know Kohacon is a free conference and it's all being organised by some brilliant volunteers, but we do need to pay for it somehow. So all donations are welcome, but there are two levels of extra benefits: "Kind Hearts" if you give over GBP 50 and "The Full Monty" for contributions over GBP 500. It will be a great conference and you could help to make it even better... See you in Edinburgh! -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/

1 0

Kohacon12 - Registrations now open!
by Chris Cormack 06 Apr '12

06 Apr '12

Hi All I'm delighted to send this mail (on behalf of the organising team) to let people know registrations for Kohacon12 are now open. http://koha-community.org/kohacon12/registration/ As you probably all know Kohacon is a free conference but we do need people to preregister so we have ideas of numbers. So please fill out the form above if you are planning to attend. It will be a great conference, a time of learning, sharing, strengthening and creating friendships, so register now. Chris

1 0

last hours before string freeze...
by Paul Poulain 06 Apr '12

06 Apr '12

Hello koha-devel, Reminder : the string freeze will be declared on monday. I've QAed & pushed all patches that were in "signed-off" status (except some 4 new features submitted by BibLibre that will wait for next release), but I'd like to point that the bug 2780 contains a *lot* of patches that I would be happy to push if someone sign-off them (there are others, but this one is really worth it for translators !!!) Thanks ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

Solr / zebra / search in Koha 3.10 => starting a workgroup
by Paul Poulain 06 Apr '12

06 Apr '12

Hello all, As you know, our main goal for the oct12 release of Koha is to introduce solr as an alternate search engine. BibLibre already explained which improvements will be added by this search engine on the blog page: http://drupal.biblibre.com/en/blog/entry/solr-developments-for-koha During the hackfest in Marseille, a group of 4 persons (Claire, Henri-Damien, Juan and Zeno) worked on how this work should be done to be introduced smoothly. The first goal being that a library wanting to run zebra still could. As some librarians could want to use another search engine than zebra or solr, we want to follow a path that would result in a better modularity. I also think that most of us agree that current search code is ugly & very hard to maintain/improve. The hackfesters have produced a drawing explaining how we could name the different packages: https://docs.google.com/a/biblibre.com/drawings/d/1ZdsQsoThYgIVSgH3LqgRZy17…, with a page on the wiki: http://wiki.koha-community.org/wiki/Switch_to_Solr_RFC#.23kohahack12 In this drawing (read from bottom to top), there are 2 main layers "Search" and "Index", that are reponsible of doing searches and doing indexing. The "Conf" object will be responsible to retrieve the configuration (current getIndexes), the "Query" object would be responsible to build the query in SearchEngine grammar, the "Plugin" object would be reponsible to deal with records before indexing (like normalizing data) Claire (from BibLibre) made a first implementation of this organization on github: https://github.com/clrh/wip-searchengine-layer/tree/master/lib/SearchEngine. Juan (from xercode), also worked on this organization, on the zebra side. His code is available also on github: https://github.com/xercode/Data-SearchEngine-Zebra. Now, Henri-Damien is continuing the work for implementing zebra with this global structure. In the meantime, 2 other directions have been followed: * Frédéric (Demians, from Tamil) wrote a daemon for zebra indexing (see http://git.tamil.fr/?p=Koha-Contrib-Tamil;a=summary) that resulted in bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7759, that document how to introduce this daemon for indexing. Liz (and maybe others) are using it without any problem. This git repository introduces some other tools, but what they effectively do is not completely clear to me (Frédéric, if you want, to add some info...) * Galen (Charlton, from Equinox) wrote some code that you can see in http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7818 and is in "needs signoff" status. The description of the bug includes a lot of things: DOM indexing for biblios (and a tool to automatically write the DOM xsl from the record.abs), and a normalizer for datas, an indexer (Koha::Indexer). Unless I've missed something (Galen, tell if I'm wrong): for now, only the DOM indexing is submitted, normalizer and indexer are not. What we all agree about: we should have a clearer way to: Normalize / Index / Search in Koha. That's great ! The structure described by the hackfester is great because it's independent from the SearchEngine you use. I think large portions (if not all) of Koha::Contrib::Tamil could be used to write the zebra indexing layer. I also think that The DOM indexing part of what Galen has submitted can be signed-off & pushed without any risk, but the normalize and indexer parts will need coordination to avoid having BibLibre/xercode working in a direction, and Galen working in another. I really like the idea of having normalizer not necessary being MARC; that could be useful in the future. That's why I propose to organize an IRC meeting (date and time to define, but that will be in Europe afternoon / US morning) with all volunteers to coordinate their efforts. I think this meeting should be regular (monthly ?) After each meeting, a summary of the conclusions would be made on the wiki and posted on this mailing-list. My proposition: if you're interested by participating to this effort, please answer to this mail. (I'll then start a doodle to find a proper time. I propose 2 hours for the duration of the 1st meeting, then, hopefully, shorter meetings) -Juan/Galen/Zeno, you're considered as being interested by this topic ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

6 10

Performance of Koha and usage of remote MySQL server
by jonathan DUPERRIER 06 Apr '12

06 Apr '12

Hello, I would like to know if the installation of Koha with a MySQL database on another server than the application may affect the performance of Koha. The MySQL server and application are on the same LAN, regardless of any order might be slowdown during query execution. Thanks for help

6 5