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