Cavorting with Koha

While Amanda (and, to a lesser extent, myself) have been exploring Drupal lately, I have been getting re-acquainted with the command-line of my GNU/Linux box. Last week I set up this blog, a sample Drupal system and, most challenging of all, a koha system.

The installation process for Koha is somewhat challenging and quite time consuming. The system installer, like the system itself, is Perl-based. The installer is smart about checking for the many and varied Perl modules on which it relies, and even gives some hints as to how to go about acquiring these modules.

I mainly followed an installation guide for version 2.2.5 of Koha and version 6.06 of Ubuntu which, unfortunately, seems to have gone offline sometime within the last two days. Google’s cache is still available. Installing Koha necessitated that I install quite a few additional Perl modules, and also that I download source of some C libraries and build packages for my system, as the versions contained in Ubuntu’s repositories were not recent enough.

I had originally intended to install Koha 2.2.9 and 3.0.0-alpha in tandem that I might compare the two systems. In the event that we decide to go with Koha, we’ll be faced with the decision between the 2.x and the 3.x versions. While the 3.x version is currently only in the alpha stage and unlikely to be reliable for a production system, a beta is scheduled for release on the 1st of February, 2008, and a stable release is scheduled for the 1st of March — dates which sit squarely in the middle of our planning and implementation schedule.

Unfortunately, my initial attempts to get Koha 3.0.0-alpha running on my machine have been fruitless. Also, I worry that in the course of making the great many Perl module upgrades which are necessitated by the new system I may break some dependency of the running, stable version.

I have been running the 2.2.9 version of Koha on my machine with some degree of success this week. Mainly I’ve been learning how to navigate and operate the administrator’s side of the system. The system is certainly functional, however, it is painfully complex and the visual layouts are offputting and nonintuitive. This makes sense to the cynic/realist in me: Liblime, the principle developer of Koha, survives by offering extensions and support of this open-source application.

As I said, I’ve had some degree of success with Koha this week. My main goals were to successfully achieve a basic level of operation (creation of records & users, successful use of reserve and check-out functions, the levying of fines, etc.) and to experiment with the obfuscation of some complex and unnecessary functionality. And I’ve accomplished both of these goals, creating a small mock dataset and withholding some branch-related functionality from the display output.

The output displayed by the Koha system is generated by Perl scripts, which parse fixed template files and compute certain sections. This is somewhat akin to the way in which PHP scripts would be processed through a CGI binary on a system without native PHP support, only there is a complementary relationship between executable script and template. The nice part about this is that it is relatively simple to modify the template files and simply excise (or comment-out) whole sections for which we have no use, such as acquisitions, subscriptions, branch transfers, and so on a so forth. It might then be possible even to remove unused tables from koha’s database (which is huge, made up of 74 tables in total) or even remove some scripts altogether. It would be nice if, at the end, we could produce a sort of Koha-lite, which could be shared with others.

A main difficulty is dealing with the massive clutter that is MARC. Our system would only really need perhaps 20-30 MARC fields at most, but even with MA

Blog type:

Catalogue blog tags: