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

Re: [Koha-devel] [Koha-patches] [PATCH] Disable _remove_stopwords in Search.pm to improve performances
by Andrew Moore 02 Jul '08

02 Jul '08

On Wed, Jul 2, 2008 at 7:28 AM, Frederic Demians <f.demians(a)tamil.fr> wrote: > _remove_stopwords takes 28% of all the time spent to do search. > This patch disable this function. Stop words should be handle > directly by Zebra, shouldn't it? Hi Frédéric - I'm all in favor of the current work to profile our application and attempt to improve it. This does look like a place where we can improve our efficiency. Have you tested to see if the zebra engine does handle the stopwords correctly? I didn't know that it did that. What should happen in the NoZebra case? Also, if we're going to stop using this sub, should we remove it and all calls to it instead of just shunting it? Thanks! -Andy _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

4 4

Fwd: DLF ILS-DI Developers' Workshop Aug 7 Berkeley CA
by Galen Charlton 02 Jul '08

02 Jul '08

Hi, The Digital Library Federation will be hosting a developers' workshop on 7 August 2008 to discuss ways to implement the proposed ILS-DI specification for exchanging ILS data with other other software such as OPAC replacements and discovery layers. I will be attending the meeting, representing LibLime. Thanks to work by Paul and others on the OAI-PMH interface, Koha is already well on its way to supporting level 1 of the ILS-DI recommendation. I will be writing an RFC to add complete support for level 1 (and possibly levels 2 and 3) of the recommendation to 3.2. If anybody else would like to attend the meeting, please contact Peter Brantley at pbrantley(a)diglib.org. More information about the meeting, including a link to the ILS-DI recommendation, is in the forwarded message below. Peter has told me that it will be possible to attend remotely via a conference call. I will also send a summary of the results of the meeting to koha-devel. Regards, Galen ---------- Forwarded message ---------- From: Peter Brantley <pbrantley(a)diglib.org> Date: Fri, Jun 27, 2008 at 11:17 AM Subject: DLF ILS-DI Developers' Workshop Aug 7 Berkeley CA Greetings - As you may know, the Digital Library Federation has released the technical recommendation of its ILS Discovery Interface (ILS-DI) Task Group. This document recommends basic, standard interfaces -- known as the Berkeley Accord -- for integrating the data and services of integrated library systems (ILS) with new applications supporting user discovery. The documentation is available at : http://diglib.org/architectures/ilsdi/ . The basic discovery interfaces permit libraries to deploy new discovery services to meet ever-growing user expectations in the Web 2.0 era, take full advantage of advanced ILS data management and services, and encourage a strong, innovative community and marketplace in next-generation library management and discovery applications. DLF is planning a developer's workshop for Thursday, August 7, at the Berkeley Faculty Club on the UC Berkeley campus, in which parties supporting the Basic Discovery Interfaces can learn more about the interfaces and how they should be implemented, meet with potential development partners, and begin the formation of a community building effective software services. Because of the nature of this meeting, we recommend that staff with a high degree of technical knowledge of your platform and bibliographic standards and protocols receive priority for attendance. The Berkeley Accord and the DLF ILS-DI recommendation are important first steps in building advanced, interoperable architectures for bibliographic discovery and use in the networked world. As soon as you have made the determination, please let me know who will be coming to this meeting. I also welcome additional recommendations for attendees who are not presently on this list. Additional logistical details will be forthcoming shortly, but please do not hesitate to write if you have questions. Thank you - -- __________________________________________________ peter brantley - executive director digital library federation | http://www.diglib.org [ university of california, berkeley [ 237 evans hall, mc 6000 [ berkeley, ca 94720-6000 __________________________________________________ cell: +1-510-599-5159 | office: +1-510-643-8665 -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 1

CGI::Session::Serialize problem (packaging changed)
by Paul POULAIN 02 Jul '08

02 Jul '08

Hello, It seems that CGI::Session had some changes in the previous release. There is a problem on cpan with it (the package has been splitted in 2 parts, and "Storable" has been renamed to "storable", and some new packages are not properly declared in cpan) Marc had a lot of problems to setup Koha, depending on the cpan mirror he uses. He will give more details here soon, but I think this has to be investigated before 3.0 official release (or, at least, it will require some warnings in the Release Notes) Cheers -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

1 0

Help on showing content from Amazon.com
by Salvador Zaragoza Rubio 02 Jul '08

02 Jul '08

Dear all We've installed 3.00.00 beta version of Koha on Debian and we want to configurate it to show content from Amazon.com. We got an 'Amazon Access Key' to be able to use the 'Amazon Associates Web Service'. We have included it in the 'System Preference AWSAccessKeyID'. What we would like to know is what is the value that should be included in the 'System Preference AmazonAssocTag'. Can you help us on that subject? We would also like to know what are the necessary steps to use content from Amazon in Koha. Thanks in advance and receive my Best regards _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 1

branching git for 3.0 / 3.2
by Paul POULAIN 01 Jul '08

01 Jul '08

Hello, With 3.0RC1 done, git should now have only bugfixes. So I think it's time for a 3.2 branch. I have no idea of how it can be done with git. Should be have 2 separate repos ? only one with a git checkout -b rel_3_2 origin/rel_3_2 locally to point on branch rel_3_2 ? That's probably the way to go. Git experts will have more ideas... We also must decide how/where commits are done. I think we should have a patches30(a)koha.org and a patches32(a)koha.org mailbox to send patches. What about a patch for 3.0 that must be ported to 3.2 ? Should the author of the 3.0 patch or the RM of 3.2 be responsible of the "cherry picking" ? someone specifically dedicated to this task ? Last question : who will be Release Maintainer for 3.0 ? To continue with the memcached thread : maybe the memcached, once done on 3.2, can be backported (for the core part only ?) to 3.0 to get speed improvement before 3.2 is released. That will be 3.0RM decision, but if asked, I would probably vote yes (once memcached stuff has been well tested on 3.2 branch) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

3 2

memcached and v3.2
by Paul POULAIN 01 Jul '08

01 Jul '08

Chris C. did some tests with memcached and it seems it's a great way to improve perfs of Koha. However, it requires some code changes. And an additionnal software installed on the server (memcached is provided on debian, and mandriva -contrib-, so it's probably not a true problem) I suggest that we add memcached option to Koha 3.2. Here could be a start for RFCs : - add a syspref usecached, to use or not memcached - memcache reference tables. I see the following reference things : context, sessions, userflags, permissions, language_*, systempreferences. Most of them are useed everytime a page is loaded in Koha (staff or opac) - memcache some other tables, that are often used : branches, itemtypes, auth_types, biblio_framework, categories, cities, ethnicity, opac_news "Memcaching" a reference table means modifying the GetTable() sub to check if the cache is already filled or not for this table : if ($usecache) { require Cache::Memcached; Cache::Memcached->import(); $memd = new Cache::Memcached( 'servers'=>['127.0.0.1:11211'], ); my $result = $memd->get("koha:reftable"); if ($result){ return $result; } else { $result = <retrieve result from SQL>; $memd->set("koha:reftable", $result, 300); # 300 : expire after 300 seconds. Can be set to more } } If you agree with this proposal, i'll add it to RFC for 3.2 pls comment. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

4 6

RFC: plan to reorganize cronjobs for overdues, notices, and fines
by Andrew Moore 01 Jul '08

01 Jul '08

Hi Koha Developers - After a brief audit of some of the code in misc/cronjobs it looks to me that the cronjobs that handle things like overdues, notices, and fines could use some work. There's a lot of overlapping functionality in the scripts in that directory, and not everything that we need for 3.0 is there yet. So, I'm hoping to find a reasonable way to get what we need easily. I'm looking for guidance here on developing a roadmap, so please speak up if you have recommendations. These are the scripts that I think we need: overdue_notices.pl - will prepare notices for items that are overdue. This increments the overdue notice counters. fines.pl - will calculate and update patron fines. This will NOT prepare notices. advance_notices.pl - will prepare notices for items that are not yet due, or have just become due. Patrons will have the option of receiving these or not. This is what will happen to many of the scripts that are there now: overduenotices-30.pl will get folded into overdue_notices.pl overduenotices-csv.pl will get folded into overdue_notices.pl overduenoties.pl will get replaced by overdue_notices.pl smsoverdues.pl will get replaced by overdue_notices.pl fines2.pl will get replaced by fines.pl fines-ll.pl will get folded into fines.pl. This script has good calculation stuff that should be salvaged. fines-sanop.pl will most likely be replaced by fines.pl. There are also some changes to the staff interface that will probably be done, as there is a similar disorganization there, but we can deal with that separately, I think. If we can agree on a general path like this, it will help us work together to reach a common goal. I can certainly get to much of this work myself in time, but there is some work going on in this directory by others and I want to make sure I'm not stepping on anyone's toes. If it looks like this path won't get us to where you think we should be, please speak up. If it looks like this is a reasonable way to proceed, please feel free to help out. Thanks! -Andy _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

3 5

updates to patron messaging
by Andrew Moore 01 Jul '08

01 Jul '08

Hi Koha contributors - I've prepared a few patches to start reworking the patron messaging stuff that we have that's not quite working as we hoped in 3.0. The patches still have some parts that still need to be cleaned up or improved in them, and I don't expect them to be applied as is, but I want to get some feedback on the implementation. http://arwen.metavore.com/~acm/PatronMessaging/ I added a tab to the opac and to the patron management part of the staff interface. These allow users to edit preferences about how to receive the different types of messages sent to patrons. There is a new cronjob advance_notices.pl that prepares messages to be sent to patrons to let them know of items that are soon due or have just become due. I expect to eventually mimic this implementation in the overdues scripts as I outlined previously. <http://doiop.com/PatronMessaging> There is also a new cronjob, process_message_queue.pl, that is designed to actually send out messages of all kinds through SMS, email, or RSS and can be extended. I hope to be able to use this for other messaging besides just these. In order to send SMS messages, there is a new C4::SMS module that makes use of the SMS::Send module on CPAN. I'm hopeful that this will help us consolidate all of the different ways to send SMS messages. I'm hoping to get this polished up a bunch next week so that it can be applied, but I wanted to send this out today to make sure that it's not a surprise when it comes. Please let me know what suggestions or questions you have. Thanks! -Andy _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

3 4

stats.pl/Stats.pm and Daily Reconciliation
by Chris Nighswonger 01 Jul '08

01 Jul '08

Hi all, I'm currently working on Bug 2008 involving the circulation report entitled "Daily Reconciliation." What I'm looking for is any kind of a specification outline for this report. The current code is quite broken. A little research in the wiki seems to indicate that the stats features in general were added in 2.2.2 ( http://wiki.koha.org/doku.php?id=en:development:roadmap2.2.x&s=stats) I'm particularly wondering what information we are looking for to be included in the Daily Reconciliation report. Should it include a line-by-line transactional summary or just entries for payments received, or simply some (which ones?) totals? Thanks, Chris Nighswonger _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 1

Re: [Koha-devel] code formatting (was: [Koha-patches] [PATCH] Bug 2176: adding SMS::Send to list of dependencies)
by Andrew Moore 27 Jun '08

27 Jun '08

Hi MJ - On Mon, Jun 23, 2008 at 4:18 AM, MJ Ray <mjr(a)phonecoop.coop> wrote: >> > Why does this patch covertly reindent everything? >> >> I didn't intend for it to be covert. [...] > > OK. Please try to mention these things in comments. It'd be a bit of > a pain to cherry-pick a patch described as "adding SMS::Send ..." and > have the dep's rewritten without warning. Alright. If it helps you out, I'll add a comment about this to my growing commit template. I have started to try to bundle refactoring patches into a separate patch before functionality. I'll try to be a little more liberal on deciding what kinds of whitespace changes to pull out into a separate patch. >> I'd really like to be able to use perltidy to make the code that I >> edit and contribute more readable. Is there a particular indentation >> style that you think would be good to use on code that I change in >> Koha? I couldn't find much about this on the wiki. > > If my notes from 1.9 are accurate, we used to use > perltidy -bar -ce -pt=2 -vt=2 -en=4 > which is almost what is in the perlstyle manual, except cuddled elses. > However, it's not been enforced much and "more readable" depends on > what you're using to read it... Super, a step towards consensus! I've opened up bug 2269 to add a perltidyrc file with these options and will work to follow it. <http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2269> > The wiki really isn't in good shape and I find it too much of a pain > to edit. Searching the mailing list and IRC is usually more useful. > Should we create a HACKING file (which is what I think GNU software > calls the file) with the above sort of info in it? I agree that the wiki is tough to edit. I'm struggling to grow used to it, too. But, I think it could be a valuable resource, so I'm personally hesitant to abandon it. I was actually considering adding a "contributors checklist" or something similar on the wiki today. I think a HACKING file would be a great contribution, too. Perhaps you could also include some information about how to make your code translatable, too. That's an area that I'm struggling to find documentation on. Thanks! -Andy _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 2