I'd like to help a little in development or code clean-up. But, wow, it looks like it's going to be a full time job just keeping track of the mailing list(s), Wiki, and IRC logs... I'd like to throw in my opinion on some development directions, but I can't figure out where I should be doing it, so I guess I'll do it here :-) This is all hobby for me; I have about 1500 books in my personal collection that I want to catalog. I don't have the same issues that "real" libraries have. In that context, I really like MARC compatibility so I can snarf data from elsewhere to avoid data entry, but I don't want to eat/sleep/breath MARC records as my way of working on the data. Yes, I understand that some librarians do want that. The library patron will never want to see MARC data, so if for no other reason than that there will always need to be an abstraction of the data, such as making bibliographic data separate from individual item copy data. I think that the current three-tier structure of biblio, biblioitems, and items is actually a very good one. There are some comments on the Wiki about the Catalogue API saying that the kohadb functions would eventually go away when the Marc stuff is done. That looks like a bad move to me. I think the functions should definitely stay abstracted at the level of add/update/delete bilbio information and add/update/delete item copy information. As long as updates are done through the API, the kohadb could go away (although I'm not convinced that is a good idea, and if updates are done through the API it wouldn't need to) but the data model should not go away. I'd like to see (and want to help) Koha extend to have some smoother handling for other item types, such as music CD's or videos, including using EAN/UPC codes like how ISBN's are used for books. Would the pure MARC version handle this equally well? Also, I've read a little on the Lib of Congress discussions for XML representation of MARC data. It seems short-sighted to me to tie the database too closely to the text-only view of MARC, down to the $ subfield delimiters. I'm not at all suggesting putting XML in the Koha database; rather arguing for a higher-level abstraction that can represent the MARC data without being too file-format specific. As a non-library person, I may be all wrong here, but thanks for letting me share my thoughts. - Alan -- ---- Alan Millar --==> am12@bolis.com <==--