LORLS

We’re getting to the point at Loughborough where we’re considering “going live” early next year with LUMP, replacing the existing LORLSv5 install that we have as our current production reading list system.  As such, we’ve just spun up a new virtual server today, to do a test LUMP install on it.  This machine has a fresh CentOS installation on it, so needs all the Perl modules loaded.  As we use Net::Z3950::ZOOM now, this was one of the modules installed (along with a current YAZ tool chain).

Once we’d got the basic LUMP/CLUMP code base installed on the machine I grabbed the existing LORLS database from the machine it resides on, plus the /usr/local/ReadingLists directory from the LORLSv5 install on there, in order to run the create_structures LUMP importer script.  Which then barfed, complaining that “Net::Z3950::RecordSyntax::USMARC” was a bareword that couldn’t be used with strict subs (LUMP, and LORLS before it, makes use of Perl’s “use strict” feature to sanity check code).

Hmm… odd – this problem hadn’t arisen before, and indeed the error appeared to be in the old LORLSv5 ReadingListsItem.pm module, not any of the LUMP code.  A bit of delving into the modules eventually turned up the solution: the new Net::Z3950::ZOOM doesn’t do backward compatibility too well.  There was a load of code in /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/Net/Z3950.pm that appeared to implement the old pre-ZOOM Net::Z3950 subroutines, but it was all commented out.  I realised that we’d not had this issue before because I’d run the importer on machines that already had LORLSv5 with an older copy of Net::Z3950 on them.

The “solution” was simply to uncomment all the sub routines under the Net::Z3950::RecordSyntax package.  The create_structures script doesn’t actually use any of the LORLSv5 Z3950 stuff anyway, so its not an issue – we just need the old LORLSv5 modules to install so that we can use them to access material in the old database.  I guess this goes to show the problems you can accrue when you reuse a namespace for a non-backwardly compatible API.

Since we released the LUMP sandbox on to an unsuspecting and innocent world a week or two ago, we’ve noticed that quite a few people have been playing with it.  Which is great – its just what we hoped folk would do.  Have a footle, take it for a spin round the block, kick the tyres, etc, etc.

However there’s been a resounding silence in the feedback front.  Either this means that:

• folk are so awestruck by its ground breaking novelty that they don’t know what to say,
• or it just works so nobody has any bug reports or enhancement suggestions,
• or is so shoddy nobody thinks its worth bothering with,
• or we released it at a really stoopid time when most University support stafff are (like us) preparing for the onslaught of the hoards.

If anyone who has played with the sandbox does have any feedback we’d love to hear it… even if its just ‘meh’… 🙂

Today was a bit of a change of pace in LUMP development – it was time to whizz up a backroom script for the librarians, allowing them to see how many modules, reading lists and different types of items were used by departments in a particular year.  On the whole this was an “old skool” CGI script that doesn’t use the LUMP XML API – just straight calls to the underlying Perl modules that wrap round the LUMP database.  This is both quick to run and quick to code, and for a simple statistics script is fine (no need for flashy JavaScript for those really).  Gary is pondering other statistics scripts we might want to produce, both derived from the existing LORLS ones and also some new ideas.  He’s going to chat to some of our librarians about those first though – no point wasting time writing code to produce information that nobody is interested in!