- Koha-devel - lists.koha-community.org

Re: [Koha] feature idea
by Pat Eyler 22 May '02

22 May '02

On Wed, 22 May 2002, Emile Snyder wrote: > Hi all, > > The desire for a new feature struck me while using my local library catalog > system recently, and I thought I would toss it out on the list. Don't know > if anyone else will find it attractive... Emile, this is an interesting idea (one I'd like to see as well), although there may be privacy concerns for some libraries. An extension to your idea might be to link out of a book/movie/something else in koha to grab an amazon (or imdb, or something else) review. As a side note, addressing ideas like these to both the koha and koha-devel lists. thanks, -pate > > I live in a fairly rural location and while the library system is fairly > large the number of volumes at the local branch is relatively small. So I > place lots of holds on books which I can then pick up later. I have found > that the way I most often select books these days is to have the telnet > interface to my library catalog open next to a browser window, and explore > various reviews at amazon, then see if the library system has a book and > place a hold on it if possible. The problem is I usually find many more > books that look really interesting than I can possibly read in the month or > so that a checkout covers ;) So the feature I wish I had is an "interest > list" that the catalog could keep for me. It kind of sounds like feature > bloat on the one hand... why don't I just keep a notepad handy? But > never the less, I keep wishing it was there. > > thanks, > -emile > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

candidacy
by Nicholas Rosasco 22 May '02

22 May '02

Since my hat (which I should have been wearing while I was out of town a few days ago -- a goodly portion of my head is now a truly fetching shade of red/pink) seems to have been chucked into the ring, I suppose I should say something. I'm a little more... taciturn? than Pat, but since what he has sent out has made sense... I'd be looking for Release managers/Coders in Chief -- Stable and Devel [yeah, most likely Chris and Paul] I'd like to see us integrate usable MARC with an eye to moving a MARC version to stable by September. Advocacy people -- International, and English [Pat, and someone else, I suppose] Ideally, I'd like to see Koha acquire more of an installed based, as I would hope to attract developers interested in making it meet there needs. The usual reasons of 'more users better' for open source apply here, and don't really need repeating :). These people would also have a brief for creating a more visible koha presence (at things like oss4lib, and for e-mailings, etc). I'd also like to see an organized effort for translations, hopefully not just by a developer. Chief Librarian -- Self explanatory, I hope. Support manager -- Responsible for coordinating documentation, and support tools (like the installer, and the conversion utils allowing you to upgrade), and for packaging for a user-friendly application. Standards Specialist -- Someone who "gets it" (more than we do) on how the commercial apps implement these standards -- preferably this would be someone from a library currently using commercial tools who is willing to let us do testing against them for compliance sake. ------ My primary goals for Koha relate directly to the above spots. * Creation of a 'pipeline' for features and versions (ie request -> schedule -> devel -> release -> tested/stable/mature -> repeat) with the logical things to make that easier (good introductory documentation, clean code, etc) * Increase of installed copies and int'l support Free software has stronger adherents where the expense of the commercial version is insupportable. Logically Koha should 'play' to that community. More installed copies means more people thinking about how Koha can be better. * A move towards becoming a viable replacement for the midsize library (short term) that participates in a larger framework (Inter Library Loan, circulation protocols). (Long term) The capability to support a national library [obviously, on larger hardware] -- especially one with more than one official language. * The creation of a community (both business and individual) that can use koha effectively -- ie, flexible enough to support a large library with specific needs and configuration requirements, but with enough user and configuration support that the small guy :) [which, btw, includes me] can use it for his home or small business library. Modularity in things like barcodes, circulation setup, and membership should permit this to happen. -- The fine print: I'm waaaay behind the coders here. I know just enough about Perl to know how much I don't know! I'm not a librarian, either. I know a little about libraries, I've worked for one, but I'll confess I don't fit firmly into either of the two primary koha demographic groups! I'm an American -- surrounded by Kiwis, Frenchman, and Canadians -- with all the viewpoint baggage :) that implies. By background, I'm a scheduling and documentation geek. I would be obliged (if elected) to lead mainly by persuasion -- I am not sufficiently skilled in perl to do an all night code-a-thon to build something. This would also makes me hands off about coding -- I'd much rather get my news on Where We Are from the wiki than the CVS updates. By temperment, I'm a tad rententive -- I much prefer things orderly, and the engineer in me can get a little obnoxious about scheduling and process. You should (before voting) ask someone else's opinion of my contributions to the project as such, as it sure as heck isn't coded features. --- All that Having Been Said, I have enjoyed being on the project, I'd like to think I've been useful, and I would be ecstatically happy to work for someone else, either as a manager/whatever, as Deputy Geek in Chief, or simply as Documentation Wonk. Best, Nick

1 0

IRC meeting and IRC logs
by Tonnesen Steve 22 May '02

22 May '02

Just a reminder of a Koha IRC meeting: When: May 30 10PM GMT Where: irc.katipo.co.nz:6667 #koha Topics: To Be Announced Also, there is a log of IRC traffic available now at: http://www.haz.cmsd.bc.ca/cgi-bin/kohalog.pl You can set your timezone and record important discussions so that others can find them easily. Steve Tonnesen

2 1

Re: [Koha-devel] Catalogue API (fwd)
by Tonnesen Steve 22 May '02

22 May '02

Alan brings up some valid points regarding switching to a MARC compatible backend database. He is not the first to raise concerns with MARC. I believe that Rosa called it "icky"? :) We definitely need to get this worked out. Here's how I see the problem: Alan is looking to use Koha for a small home collection. Let's call this a 2,000 item library and call it the low end of the Koha user spectrum. Note that low end here is not intended to be an insult or a brush off, it's just an indication of the number of items in the collection. At the high end, we'd have collections with 1,000,000 items or more. I believe that most of those large libraries would insist on being able to directly view and edit bibliographic data using a MARC interface. In other words, if they were going to enter an author for a book, they'd want to see a 100 tag with an 'a' subfield to enter the name in, and a 'd' subfield to enter the date of birth/death in. In the small libraries, they'd just want the word author with a text field beside it.

2 2

my candidacy
by Pat Eyler 20 May '02

20 May '02

Given that I've been nominated as the Koha Dictator, people should know where I stand on things. Hopefully the following helps: Overview I'm most focused on a three issues: cleanliness of code (including inline comments and a solid testsuite), inclusion of features for other libraries (e.g., MARC), and the uptake of Koha in the larger (international) market and the Open Source world. Each of these is discussed below: Code Cleanliness - I believe that to be successful code need to be legible, testable, and understandable. Everyone working on it needs to have a sense of ownership so that they can go in and fix problems, add functions, and be able to contribute them back to the community at large. I'm a firm believer in test driven design, refactoring, and many other tenants of the eXtreme Programming culture. Feature Inclusion - I believe that Koha is a great system which can be made better. As the community adds features of interest to potential users, we need to ensure that a) we're adding them in a maintainable way, b) we're not excluding current users, and c) we're providing backwards-compatability and/or migration tools. Some of the features that seem most pressing to me are: an installer, MARC, Z39.50, and better front-end/back-end modularization. Koha Uptake - For Koha to be successful outside it's current market, I believe that we must succeed in the two areas described above. I also feel that we need to reach out to potential users and developers. We need to develop a strategy of approaching (or creating) potential partners to help push Koha into new territories (e.g., Latin America). How do I propose getting there? I think that our existing road map is a good place to start. I'm encouraged by the amount of coordination that already occurs on the list and in irc, and encourage more of this. If elected, I would like to use a staff (described below) to help build and lead the community. To encourage code cleanliness, I feel that we need to encourage the development of tests and documentation. Liberally seeding the codebase will make a good start. Encouraging the addition of tests for new features before checkin (indeed, the successful passing of the complete testsuite before checkin) will also be a great help. Frequent building of the project's POD and automatically posting it to a community website would be good too. I'd also like to see bugzilla (or the tracker in SourceForge) used to track problems and reward top bughunters. To drive feature inclusion, I believe that following a roadmap, communicating within the community, and keeping a development vs. stabilization separation (with release managers on both sides) will be the key. As librarians, developers, and commercial interests work together to define release targets, then a release manager guides development toward the target, We should see an organized inclusion of features as we progress toward a Koha 2.0 release. Building a larger Koha community through uptake of the project will require evangelization and coordinated communication to selected communities. We will also want to encourage developers and organizations to adopt Koha by supporting them through the learning curve. In some cases, this will mean encouraging commercial interests to start supporting koha in their region (or helping to form commercial interests to support koha in their region). What are my liablities? I'm not the perfect candidate, and may not even be the best candidate. Here are some reasons you may not want me to be the Dictator. 1) I'm pretty new to the whole project. 2) I come from a different coding background. I'm a sys-admin who really believes that OO and XP are better. 3) I'm likely to be very busy with other things during the summer. This might mean that I can't put in as much time as I'd like to. 4) I have the typical hacker personality ... I can come off as abrasive, annoying, and abrubt. 5) I can be quite a pest about getting things done.

2 3

Nominations etc etc
by Rachel Hamilton-Williams 20 May '02

20 May '02

Howdy, so how are we getting on for nominations to the key post of Koha Dictator. I notice a certain amount of shyness at the moment, so how about some nominations from the floor? Oh look - I made some :-) /me hereby appologises in lieu of asking permission to nominate people The candidates are .... Me - well had to be really: Con's - am a Katipo person, haven't got a huge amount of time, am neither techy nor library, am likely to be influenced by what people are paying us (katipo) to do, have OOS so not fab at massive amounts of flame waring etc, can't spell (and this is important it seems). Pro's - good at being bossy and delegating, focused on getting things that matter done, have resources if necessary, have clear (in own head anyway) objectives for Koha, used to mediating between developers etc. Pat - Con's - probably busy, Pro's - not an active developer, seems fairly organised (if you can judge these things off a few e-mails), not a Katipo person, so better "neutrality" and sense of Koha moving beyond being a Katipo project. Rosalie - Con's - busy, public library focus, has had some time off with a broken wrist and may already be over committed, also a bit prone to OOS so not good at flame wars etc, not techy. Pro's - is good public "face" not at all open-source rabid hacker (appologies again to all who are offended :-), actually runs Koha in a live library, already answers lots of queries from libraries about koha, is a library person, has vested interest in Koha's sucess, also has resources behind her if necessary. Nick - Con's, Probably busy; Pro's - does simple documents for users (FAQ etc) , so knows Koha well but isn't actually a developer, not a Katipo person, so better "neutrality" and sense of Koha moving beyond being a Katipo project. Sorry - Nick I feel I should know more but them's the breaks. Roger - Con's, Probably busy (well who isn't :-); Pro's - documents stuff for techys (install file etc), so knows Koha well but isn't actually a developer, not a Katipo person, so better "neutrality" and sense of Koha moving beyond being a Katipo project, has been "point man" on the koha list helping people with their install probs, in touch with novice uses. Roger again sorry - you do such a lot and I know so little but please embelish. Anyone else - sorry I don't know everyone that well - so "proper" pro and con statements would be a great addition, and anyone else keen to throw their hat in would be welcome I'm sure. PEOPLE NOT NOMINATED I haven't nominated anyone who's actually working on the code (I think). It seems too much for someone to work on the code and be the dictator and hold down a day job IMHO. Let the campaigning or furious backpeddling begin :-) Cheers Rachel _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org

3 2

Catalogue API
by Alan Millar 17 May '02

17 May '02

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(a)bolis.com <==--

2 2

marc stuff
by paul POULAIN 17 May '02

17 May '02

I've commited my marc stuff in the main branch. I've done this because when i asked for a marc branch i thought the main branch was the stable one. As Chris explains me it was the dev one, i think we don't need a marc branch. Why ? Because I want the marc-compliance for september-02, so i will have a hard work on it, and it should be in the next release (1.4 ?) Hope kiwis have had a good night, and americans will have to. See you tomorrow -- Paul

2 3

Re: [Koha-devel] Question on proper/preferred DBI usage?
by Alan Millar 16 May '02

16 May '02

I definitely do not want to get into a flame war on this, so if it turns that direction, I'll drop the subject. On Thu, May 16, 2002 at 03:42:30PM +1200, Gynn Lomax wrote: > The reason it has been done this way is simple: > I like to be able to see what values I am assign to where. > With the values embedded into the query it means I can directly see what > they match up with, e.g.: > > $query = "Insert into biblioitem set > biblionumber = $biblioitem->{'biblionumber'}, > itemtype = $biblioitem->{'itemtype'}"; I haven't looked at enough of the code, but I haven't see much of that in the code. I see things like: $sth=$dbh->prepare("insert into biblioitems (biblioitemnumber, biblionum ber, volume, number, itemtype, isbn, issn, dewey, subclass, publicationyear, pub lishercode, volumedate, volumeddesc, illus, pages, notes, size, place, lccn, mar c) values ($biblioitemnumber, $biblionumber, $q_volume, $q_number, $q_itemtype, $q_isbn, $q_issn, $q_dewey, $q_subclass, $q_publicationyear, $q_publishercode, $ q_volumedate, $q_volumeddesc, $q_illus, $q_pages, $q_notes, $q_size, $q_place, $ q_lccn, $q_marc)"); and I'm definitely having a hard time matching up which variable goes with which column name. > With the bind values method you get: > $query = "Insert into biblioitem set > biblionumber = ?, > itemtype = ?"; > > followed by later: > $sth->execute($biblioitem->{'biblionumber'}, $biblioitem->{'itemtype'}); > > While for this simple example it is easy to see which value matches up, for > more complicated queries, and those that have a lot of values it can start > to get mor confusing. With this method, as well as the example above (straight from marcimport.pl), in my opinion the main problem is formatting. Compare, for example, the following actual code: ------------------------------------------------------------- my $q_isbn=$dbh->quote($isbn); my $q_issn=$dbh->quote($issn); my $q_lccn=$dbh->quote($lccn); my $q_volume=$dbh->quote($input->param('volume')); my $q_number=$dbh->quote($input->param('number')); my $q_itemtype=$dbh->quote($input->param('itemtype')); my $q_dewey=$dbh->quote($input->param('dewey')); my $q_subclass=$dbh->quote($input->param('subclass')); my $q_publicationyear=$dbh->quote($input->param('publicationyear')); my $q_publishercode=$dbh->quote($input->param('publishercode')); my $q_volumedate=$dbh->quote($input->param('volumedate')); my $q_volumeddesc=$dbh->quote($input->param('volumeddesc')); my $q_illus=$dbh->quote($input->param('illustrator')); my $q_pages=$dbh->quote($input->param('pages')); my $q_notes=$dbh->quote($input->param('note')); my $q_size=$dbh->quote($input->param('size')); my $q_place=$dbh->quote($input->param('place')); my $q_marc=$dbh->quote($input->param('marc')); $sth=$dbh->prepare("insert into biblioitems (biblioitemnumber, biblionum ber, volume, number, itemtype, isbn, issn, dewey, subclass, publicationyear, pub lishercode, volumedate, volumeddesc, illus, pages, notes, size, place, lccn, mar c) values ($biblioitemnumber, $biblionumber, $q_volume, $q_number, $q_itemtype, $q_isbn, $q_issn, $q_dewey, $q_subclass, $q_publicationyear, $q_publishercode, $ q_volumedate, $q_volumeddesc, $q_illus, $q_pages, $q_notes, $q_size, $q_place, $ q_lccn, $q_marc)"); ------------------------------------------------------------- with this functional equivalent: ------------------------------------------------------------- $sth=$dbh->prepare("insert into biblioitems (biblioitemnumber, biblionumber, volume, number, itemtype, isbn, issn, dewey, subclass, publicationyear, publishercode, volumedate, volumeddesc, illus, pages, notes, size, place, lccn, marc) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) "); $sth=$dbh->execute( $biblioitemnumber, $biblionumber, $input->param{'volume'}, $input->param{'number'}, $input->param{'itemtype'},$input->param{'isbn'},$input->param{'issn'}, $input->param{'dewey'}, $input->param{'subclass'}, $input->param{'publicationyear'}, $input->param{'publishercode'}, $input->param{'volumedate'}, $input->param{'volumeddesc'}, $input->param{'illustrator'}, $input->param{'pages'}, $input->param{'note'}, $input->param{'size'}, $input->param{'place'}, $input->param{'lccn'}, $input->param{'marc) ); ------------------------------------------------------------- I'm sure it is just a matter of what each person is accustomed to, but I can match up parameters easier in the second example than I can in the original. > For the very few queries I have run across that are executed more than once, > the values being put into them are an unknown list (in terms of length), > e.g. > > $query = "Insert into deleteditems values (" > foreach my $value (@results) { > $value = $dbh->quote($value); > $query .= "$value,"; > } # foreach > > and I'm unsure if the bind values method can handle this, so avoided it. This code snippet looks like it is inserting an "unknown list" of column values into a table, on the assumption that the unknown list just happens to match up with the exact correct order of columns in the table. This is different than the original issue which is in the context of inserting multiple rows, not columns. I'm definitely going to be stepping into hot water here, and so I must apologize in advance for that. But as to the columns, it seems to me to be unsafe coding practice to insert values into a table without column names, because somebody somewhere is going to do some db modification, whether through custom changes or version upgrades, and some column will missing or out of order and it will break. Hashes perhaps are a good solution for this type of thing. In any case, the bound parameter method works just fine for this: $query = "Insert into deleteditems values (" foreach my $dummy (@results) { $query .= "?,"; } # foreach $query=~s/,$/\)/; $sth->execute(@results); And there is probably a shorter way to do the correct number of question marks via a count of @results. > The other advantage of the method I have used is that you can print out the > entire query before it is executed - so you can examine it for bugs. Whereas > with the bind value method you never get to see the query in it's entirety. OK, with the quoted method you only have to print one thing, while with the bound method you have to print more. That's true. I sure don't want to start a flame war, and if it sounds like I am, please just ignore me and I'll drop it. Thanks for the education on another point of view. - Alan -- ---- Alan Millar --==> am12(a)bolis.com <==--

5 4

spanish work on koha
by Pat Eyler 16 May '02

16 May '02

Nick, How far do we want to go in getting koha in front of hispanic developers and users? The recent moves in Mexico by Hispalinux may prove another good avenue for us to approach this potential audience. -pate

1 0