Erik Berglund wrote:
David Everly wrote:
Sounds good. I would be glad to have this come after 1.2, since I am
eager for 1.2 to become stable.
We'll make sure it doesn't postpone the stable release too much. In
case we decide to implement it now, that is.
as said in a different thread i identified a hard-coded book-id system
as first weak point in emilda and tried to isolate this task to some
functions
rationale :
book-ids are not "clean" primary keys in existing
dummy-x-implementations of library-systems ALAS
thos guys tried to encode funny stuff like library-parts etc. in
book-ids and even worse use also non-digits since mature barcodes allow
full ascii :-(
so customisation could be done ALREADY in
1) it has to be verified still if the rest of the code honors this approach.
2) main issue (if i am right ) is the linkage between "internal"
book-ids in sql-tables and system-control-number in ZEBRA/MARC
2a) to use a internal 10-digit key and some user-preferable "external"
encoding will confuse librarians i think
2b) regex-match was also the first idea i had but it is too weak for
existing brain-damaged encodings
2c) ideally there should be no limitation to the MARC
system-control-number which should be identical to the book-id to keep
things flexible and simple (if MARC needs a number and no characters
those should be mapped 1:1 to numbers IMHO
e.g.
i have two very distinct schemes of ean-13 codes from different
libray-programs which need to be honored and i will have to use a 3rd
scheme for all "new" items :-(
it will be very hard to pursue the librarian to relabel more than 14k items
dont worry, be happy >:->
wolfgang
|
