[Koha-devel] dev_week / rel_3_0 zebra API

[Joshua Ferraro]

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 at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS