On Fri, Sep 29, 2006 at 04:57:51PM +0200, Paul POULAIN wrote:
I want to summarize what is done on dev_week (& synched to rel_3_0) and check (with Kados) that i'm right :
* cataloguing API : - joshua, you have modified recently *Biblio.pm* to change the sub names, to have something using our coding rules. For example, NEWnewbiblio is now NewBiblio. The parameters seems unchanged. Correct, although I did a bit of cleanup in some places where there were gaps. For instace, there is a new sub called DelBiblio that does more than the previous one did.
- we don't see anything commited in acqui.simple/addbiblio.pl and additem.pl, meaning either you have forgotten to commit them, or that it is still to be done. Pls tell us ;-) I forgot to commit ... will do today.
- AddBiblio / ModBiblio ... are now the ONLY point of entry to add a biblio. That means the parameter MARC=OFF is definetly gone & abandonned. For dev_week/2.4, this is true. dev_week/2.4 is strictly for libraries that use MARC.
* Search API : - The search on catalogue can be done with Search.pm, subs BuildQuery & GetRecords. All previous subs (cataloguersearch... are deprecated & can/will be removed from the code) Not quite ... they are deprecated entirely from the OPAC. See the next point.
- the search in librarian interface is still search.marc/search.pl, and don't use this new definitive API yet. There is an API wrapper that works, though needs many improvements. This means that anything calling catalogsearch will "work", or minimally, it should return results. I plan to expand on the wrapper a bit in the coming weeks, but eventually, (in rel_3_0), we'll want to re-write all the Intranet searches to use the new API.
- the search in OPAC is search (opac-search.pl & opac-zoomsearch.pl are deprecated too & can be dropped). Is there a reason why you called it "search" only (no .pl & no opac-xxx) ? It could be opac-search.pl. My goal was to shorten the URI for the user to one that makes more sense, but it's probably better to do this with mod_rewrite.
* where can we help ? we are going to merge the code to rel_3_0 and continue cleaning, but should we do this on dev_week BEFORE merging, or on rel_3_0 AFTER merging ? I would recommend sticking with rel_3_0, merge in code from dev_week/2.4 as you see fit. I'll catch up with you once dev_week/2.4 is production- ready for the minimum requirements of LibLime's Koha-Zebra clients (ie, no UNIMARC, no MARC=off, no multi-language, etc.).
Looking forward, I think it's going to be very important to define roles for each of our developers. Koha's codebase is simply too large for one developer to try to maintain. Perhaps at an upcoming meeting we can discuss this further. Hope that helps, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS