RE: [Koha-devel] Biblio.pm Choices IMPORTANT

[Tümer Garip]

Hi Josh,
Regarding difference of dev-week biblio.pm and HEAD biblio.pm

1- Dev-week biblio.pm has got $bibid variable but only as a variable
name. There are no marc_biblio, marc_word or marc_subfield tables that
they use. All the version 2_2 function names are kept to allow 2_2
intranet & opac scripts to work without modifications. So going ahead
and doing a search&replace all $bibid to $biblionumber will not break
anything.

2- Dev-week biblio.pm contains lots of the unnecessary code left over
from 2_2

3- Dev-week biblio contains a routine called zebraop which only gets
called twice.Once for 'specialUpdate' updating the zebradatabase and
once for 'recordDelete' deleting the database.
All handling of  by which user to which port is done at Context.pm level
redaing the configuration file koha.conf or newly renamed to koha.xml
(by me) to prevent confusion with the 2_2 koha.conf. New one is an xml
file which contains both mysql and zebra configurations.

4- Dev-week biblio.pm also contains some new code to be able to update
holdings data in marc records (such as onloan and holdingbranch).

5-Dev-week biblio also contains sorting of callnumbers according to LC
rules by default (NEU uses LC) which will have to be looked into and set
rules on how to sort for Dewey,LC or any other. Another discussion
subject

6-HEAD biblio.pm is clean of unnecessary code. All but a few $bibid
variables are removed

7-HEAD biblio.pm introduced new routines strating with REAL thus changed
the logic in database handling.  I could not get head to work properly
so I do not know whether new bugs introduced or not.

8-Adding zebra support to any biblio.pm is very easy with zebraop. Any
time you write a marc record to the database just call zebraop with the
biblionumber. Any time you want to delete a marc record from the
database call zebraop prior to actual deletion.

9-As long as HEAD biblio.pm code works with mysql database properly just
adding zebrasupport for it should not be difficult.

10-I also we should clean up this biblio once and for all. But if you
need zebrasupport today by simlply adding a few fields to your existing
koha db then dev-week biblio.pm should be kept otherwise for a clean 3.0
HEAD biblio.pm forge dev-week biblio and start debugging and redesigning
HEAD biblio.pm. I personally will not be able to do that as I have
production on dev-week biblio.pm and now adding zebra support to
AuthoritiesMarc.pm which by the way uses zebraop logic

11-Regarding char_decode: I already have Expat installed and still could
not get M:F:X to work properly. But I also think that we should get rid
of it otherwise its always going to be a problem as new formats or
languages are added to KOHA. I also stroongly believe that all data
within KOHA & ZEBRA should be UTF-8 and non UTF-8 handling should only
be allowed when importing or exporting of MARC records

Cheers
Tumer



-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Joshua Ferraro
Sent: Wednesday, May 24, 2006 3:38 PM
To: address@hidden
Subject: [Koha-devel] Biblio.pm Choices IMPORTANT


Hi folks,

I've been looking at merging Biblio.pm from dev-week and HEAD and it
looks like there are a few choices that need to be made ... I'd like to
get your feedback on these.

(BTW: Tumer, go ahead and commit all the Biblio.pm stuff you've got to
HEAD, we'll deal with the conflicts after the fact ...)

1. in HEAD we have 'z3859_extended_services', a routine capable of
handling all the Z3859 extended services offered by Zebra, as well as
'set_service_options', which sets the service options before calling
z3859_extended_services. But in dev_week, it looks like 
that's handled with 'zebraop' and when zebraop fails it falls back on
zebraopfiles ... 

So which of these routes shall we take, perhaps a combo of both
approaches?

2. in HEAD we have no more bibid, is that going to cause any strange
conflicts in dev_week code (didn't spot anything specific).

3. in HEAD we have 3 types of subs, REALXXX, NEWXXX, something_elseXXX
... can't we just have one type of sub? Any reason we can't just 
completely clean up this API once and for all?

4. char_decode (you knew it was coming :-). Tumer, can you check the
mail I sent earlier about encoding and see if installing XML::SAX::Expat
solves your problems with MARC::File::XML's handling of encoding? If we
have to stick with char_decode, then so be it, but I'd really like to
have a more standards-compliant way to handle encoding in both MARC21
and UNIMARC. What this means is that in addition to managing the proper
encodings (to and from MARC-8 in MARC21, and to and from the appropriate
encodings in UNIMARC), Koha should also handle the leader (for MARC21)
and tag 100 (for UNIMARC), and properly set the encoding when all is
said and done. Internally, I vote that we store everything as UTF-8 in
all 
circumstances.

That's all for now ..

Cheers,

-- 
Joshua Ferraro               VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE
President, Technology       migration, training, maintenance, support
LibLime                                Featuring Koha Open-Source ILS
address@hidden |Full Demos at http://liblime.com/koha |1(888)KohaILS


_______________________________________________
Koha-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/koha-devel