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

Re: [Koha] Fwd: ZOOM battles
by Rob Weir 05 Dec '06

05 Dec '06

Hi Luis, I think one piece of the puzzle is to make sure you have the Net-Z3950-ZOOM module installed. I hunted all over the internet and couldn't find a W32 build of this module. I was about ready to try building it myself, but last night I found http://theoryx5.uwinnipeg.ca/ppms/. They have a link where you can submit a build request for any w32 packages that aren't available, and they will try to build it for you. I submitted a request and within an hour had an email back that a package was ready. How's that for service! So if you need a w32 build of Net-Z3950-ZOOM, you can now download it at http://theoryx5.uwinnipeg.ca/ppms/zips/ I downloaded the package last night and verified that it installed properly in ActivePerl 5.8.8.819. This morning I added it to the install package of Perl modules at http://koha.rwjr.com/ I also know that you need the latest Yaz toolkit that is available from http://www.indexdata.dk/yaz/ I think the latest version is 2.1.40. They do have a install package for windows that seems to work fine. Do you have Net-Z3950-ZOOM and Yaz installed? If not, try adding those pieces. That's how much I have been able to do so far. I have not had time to test this with Koha, but hope to do so soon. Let us know if you make any progress. Rob > -------Original Message------- > From: Luís Ferreira <anarka(a)gmail.com> > Subject: [Koha] Fwd: ZOOM battles > Sent: 05 Dec '06 15:55 > > ---------- Forwarded message ---------- > From: LUíS FERREIRA <[LINK: mailto:anarka@gmail.com] anarka(a)gmail.com> > Date: Dec 3, 2006 4:13 PM > Subject: ZOOM battles > To: [LINK: mailto:koha-win32@nongnu.org] koha-win32(a)nongnu.org > > Heys :) > Looking at the changelog, making ZOOM work on windows with 2.2.7 should be > pretty straitforward... but i haven't been able to do it, if it seems it's > almost working we get another problem, so my question is: > > Is there a tutorial to get ZOOM and Z39.50 search working in Windows using > Koha 2.2.7 ? > > I'm sorry but i have searched quite a lot and i get the idea the process > is pretty simple but... i just don't get it :) > Thanks in advance for any replies. > > -- > Smile... tomorrow will be worse. > [LINK: http://anarka.org] http://anarka.org > > -- > Smile... tomorrow will be worse. > [LINK: http://anarka.org] http://anarka.org > -------------------- > _______________________________________________ > Koha mailing list > [LINK: compose.php?to=Koha(a)lists.katipo.co.nz] Koha(a)lists.katipo.co.nz > [LINK: http://lists.katipo.co.nz/mailman/listinfo/koha] > http://lists.katipo.co.nz/mailman/listinfo/koha

1 0

Fwd: ZOOM battles
by Luís Ferreira 05 Dec '06

05 Dec '06

---------- Forwarded message ---------- From: Luís Ferreira <anarka(a)gmail.com> Date: Dec 3, 2006 4:13 PM Subject: ZOOM battles To: koha-win32(a)nongnu.org Heys :) Looking at the changelog, making ZOOM work on windows with 2.2.7 should be pretty straitforward... but i haven't been able to do it, if it seems it's almost working we get another problem, so my question is: Is there a tutorial to get ZOOM and Z39.50 search working in Windows using Koha 2.2.7 ? I'm sorry but i have searched quite a lot and i get the idea the process is pretty simple but... i just don't get it :) Thanks in advance for any replies. -- Smile... tomorrow will be worse. http://anarka.org -- Smile... tomorrow will be worse. http://anarka.org

1 0

Access to Koha API
by Alex King 28 Nov '06

28 Nov '06

Following on from my last email, I wonder if any thought has been given to exposing the Koha API to other external programs? It seems to me that there is a separation between the web-UI and library functions (in modules/C4) already, and of course there are command line scripts which use the library functions. (Library could be ambiguous in this context, I mean in the programming sense). Has any thought been given to exporting these functions via XML-RPC or some other RPC or web services type of interface? This would allow me to write my scripts in python, as well as other tools and possibly UIs to be written separately from the main Koha code. Thoughts? Cheers, Alex

3 3

Re: how to automate adding of items.
by Alex King 28 Nov '06

28 Nov '06

I'm replying to my own message (below,) to let folks know where I got to and to re-ask the same questions on -devel, because it got nowhere on the user list (perhaps not surprisingly) What follows relates to Koha 2.2, and is probably all simple stuff to people who are actually involved in Koha devel stuff. However I thought it might be useful to others in my position. Records in the Koha "reservoir" (uploaded through the "upload MARC records in reservoir" function in the ui) exist in the marc_breeding table, with an ISBN and a "breedingid" key. To add an item manually through the ui, the user goes first to "Catalogue", "Add Biblio", which corresponds to acqui.simple/addbooks.pl. A search on the ISBN calls acqui.simple/isbnsearch.pl which in my case brings up one result if the ISBN is in the reservoir. I can do this automatically easily enough by searching for the ISBN in the marc_breeding table. Next the user clicks "Add biblio" next to the listed item. This calls acqui.simple/addbiblio.pl with the breeding_id set which takes them to a screen with all the cataloguing details in the browser window. This is presumably so the user can check and correct those details for their library. In our case, all the details in the reservoir have come from a single trusted source and no details need to be changed. The user then clicks an "Add biblio" (which I believe POSTs to acqui.simple/addbiblio.pl), and actually adds the biblio record in the db. modules/C4/Biblio.pm is helpfully documented with an explanation of the old-DB and MARC-DB databases. I don't know without further research whether koha2.2 still keeps up two parallel data sets, but it certainly seems it would be simpler to manipulate Biblio data through the API provided than through direct DB access. I also suspect the complete MARC data is transferred to the browser for the user to review, then it is transferred back to acqui.simple/addbiblio.pl via a post (with "op" set to "addbiblio"). So in other words the data probably goes from the marc_breeding table to a biblio entry only via the browser and there is probably no API call to transfer this data directly. I this is what is making me think what I am trying to do is too difficult. Once the biblio is added, the browser redirects to acqui.simple/additem.pl, with a bibid set to reflect the newly added biblio. This screen allows the user to set data related to the item (barcode being the most important one for me.) This then POSTs back to acqui.simple/additem.pl to add the item (calling NEWnewitem). My lack of perl is hindering a comprehensive understanding, but it seems to me what I am trying to do isn't going to be straightforward. It's probably going to be cheaper for the client to manually enter their items (~2000) than for me to work out how to automate the process. Cheers, Alex Alex King wrote: > I'm needing some assistance with adding (biblios & items) into koha > automatically. > > The biblio data is (for the most part) already in the reservoir. > > I have a list of matched ISBNs and barcodes, and I need to "create" a > biblio from data in the reservoir and add an item. > > I can do this easily enough through the web UI, but there has to be a > better way to enter the data automatically, given that I have the list > of ISBNs and barcodes already in a text file. > > I am comfortable enough with scripting and accessing the mysql tables > directly. I'm not though familiar enough with the koha database to > know what to do there. I know it's not simply a matter of adding > records in a single table. > > Can anyone point me to any scripts I can start from or suggest better > ways to achieve what I'm trying to do? My thinking is to look at the > cgi scripts and see what they are doing behind the scenes and write > non-interactive scripts that do the same thing. My guess is they > probably call library routines in the "C4" directory, and I could hook > into the same library routines. > > Cheers, > > Alex >

3 3

3.0 zebra database creation on rel_3_0
by Paul POULAIN 28 Nov '06

28 Nov '06

As suggested & discussed with joshua, i've worked on zebra database creation today. I still have some tests to do, but it begins to be useable... I summarize : - All config files are now located in misc/zebra directory. PLEASE, if a .att, a .abs ... has to be improved, do it here, in the correspounding file. - All tools to migrate from a 2.2 to a 3.0 are now located in misc/migration_tools/22_to_30 directory - in misc/migration_tools, the rebuild_zebra.pl script will : * read your koha.xml file * create all directories needed, for both authorities & biblios * copy the needed files from misc/zebra, depending on your marc flavour * create the *-config.cfg files, with the correct directories * dump the authorities & create the zebra DB for them * dump the biblio & create the zebra DB for them I tried to put many informations while doing the job, let me know if it works for you, and, if not, pls let me know where it fails. Eventually, fix the script your self, you'll be welcomed. WARNINGS : - for instance, the script dumps only 100 biblios & 100 authorities. - there are many parameters to this script, they are not all working. - authorities zebraidx don't work atm, i'm sure i'm not far from the solution to the problem - Biblios zebraidx used to work in the previous commit, but, atm, as i've added authorities, i'm not sure they work. I'll try to fix this, not tomorrow (i'm not at office), but thusday, for sure) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

1 0

documentation for uploading to cvs repository
by Cindy Murdock 28 Nov '06

28 Nov '06

Hi all, Is there documentation anywhere on the proper way to upload files to the cvs repository? We want to upload updates to the ccfls templates, but Kyle informed me that he's having difficulty getting them uploaded, and asked me to drop you a line about it. Cheers, Cindy ______________________ Cindy Murdock Network Admin Meadville Public Library | CCFLS meadvillelibrary.org | ccfls.org

2 1

about virtual shelves
by Paul POULAIN 28 Nov '06

28 Nov '06

Owen & chris were speaking on the chat, last (my) night of virtual shelves. 2 notes on their discussion : - I agree it's strange to have virtual shelves based on items. Unless i'm mistaken, it's something Steve tonnesen wrote, and, as he disappeared, we will never know if it was a design mistake or a good idea. I still vote for "designe mistake". - about deletion of items/virtual shelves : I tried, in rel_3_0/updatedatabase, to define all SQL constraint to manage such things. So, virtual shelves entries should no more be connected to deleted items. However : nothing is done in 2.2 & it requires to have innoDB & not myIsam table structure (which updatedatabase also achieve) HTH -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

1 0

Re: [Koha-devel] New Feature: Improved Z39.50 Client
by Waylon Robertson 28 Nov '06

28 Nov '06

On a piece of work i have completed.. i had to use mysql 3.23... Ubuntu, derivitive of debian, installs mysql 5 by default. It was an interesting challenge, uninstalling 5, and pinning it, then used mysql 3.23 from a redhat linux distro, using 'alien' to rpm2deb and install with scripts. uninstalled dbd::mysql, which under Ubuntu, was a matter of uninstalling a deb package.... installed via cpan the needed modules, that compled against mysql-devel-3.23. Went well. No problems. Waylon. ----- Original Message ---- From: José Parrella <joseparrella(a)gmail.com> To: Jerry Van Baren <gerald.vanbaren(a)smiths-aerospace.com> Cc: koha-devel(a)nongnu.org Sent: Saturday, 4 November, 2006 1:07:07 PM Subject: Re: [Koha-devel] New Feature: Improved Z39.50 Client Jerry Van Baren escribió: > FWIIW, you can "pin" versions using /etc/apt/preferences so you could > pin MySQL to 4.* with a more advanced Debian system. You can also > downgrade a MySQL 5.* installation to 4.*, but that might be tough > because of dependencies... it is probably better to install Debian > testing/Etch without MySQL, pin MySQL to 4.*, and then install MySQL > (which will install 4.x since it is pinned). Sure. However the dependencies on libmysqlclient varies, and DBD::MySQL and other already-packaged modules which depend on libmysqlclient might need to be purged and compiled using dh-make-perl or any other helper, or just installed manually. I planned to recompile Sarge's source package under Etch; I guess that's the nicest way. Of course it's possible to have Koha in Etch (I had it, just decided to fallback to Sarge) it's just quite more complicate to achieve, a little bit unmanageable and currently highly complex to do by means of an official Debian package. Jose -- José M. Parrella -> Debian Sid, k2.6.17.13 Escuela de Ingenieria Electrica Universidad Central de Venezuela -> ucvlug.info _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel Send instant messages to your online friends http://au.messenger.yahoo.com

1 0

Library-specific Code in rel_3_0
by Joshua Ferraro 27 Nov '06

27 Nov '06

Hi guys, This is a reminder that if you are committing something to Koha that is not universally useful, please create a system preference. I have come across several changes that are not universal and will need to be fixed in rel_3_0: * in member management, surname is all caps * titles are in french rather than english in english prog templates ?!?! * displaying "Branch: 1" instead of "Branch: Branchname" * use List::MoreUtils qw/uniq/; used in request.pl There are many other examples ... it's important to remember that the code you commit to rel_3_0 should not be library-specific. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

3 3

Zebra and Directory Structures
by Joshua Ferraro 27 Nov '06

27 Nov '06

Hey guys, I'd like to propose that we reflect for a bit about how to structure the zebra components within rel_3_0 before we diverge too much. There are currently three zebra databases for a given rel_3_0 install, and it's likely there will be more in the future (if we have a metarecord bibliographic for instance), but for now we have: biblios (biblio records) authorities (authorities records ) public (for a publicly accessible Z39.50) Each of these needs its own 'tab' directory, as well as registry locations, etc (for the database files). We also have at least two MARC types to deal with, with more to follow if our plans for world domination succeed :-): usmarc and unimarc. Each flavor of MARC needs it's own tab files. I propose we create a standard for managing the zebra files as follows. The installer creates one directory 'zebra' with the following contents: $ ls zebra/ unimarc usmarc then, in each of these we'll have: $ ls zebra/usmarc/ authorities biblios public within each of these we'll have in turn: $ ls zebra/usmarc/biblios/ key lock recordDelete register shadow specialUpdate tab tmp This way, if I have one server with three disks, I can have the following distribution: Filesystem Mounted on /dev/sda1 / /dev/sda2 /koha/zebra/usmarc/biblios /dev/sda3 /koha/zebra/usmarc/authorities (ie, in this way, zebra biblios, authorities and mysql don't compete for disk usage). I also propose we attempt to keep unimarc and usmarc in as close sync as possible, using the same naming conventions, etc., to make sure we don't get confused. (I noticed that in the unimarc directory, there are directories with capital letters as the first letter of the dir ... which is different than in usmarc ... we should pick one method and stick with it ) All of the non-tab files (like koha.xml, ccl.properties, pqf.properties, zebra-biblios.cfg, zebra-authorities.cfg, zebra-public.cfg should IMO go into the koha etc directory, but in CVS we should have: misc/etc/usmarc/ misc/etc/unimarc/ because the files are different for each flavor of MARC. Or should we store these config files in the tab dir? Finally, once we decide on a method, lets clean up CVS by deleting all the extra directories and files (like zebraplugin and misc/zebra). Comments, suggestions? -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

2 3