Way back in 2004, I first set out to build an application that could serve as an improved user interface to Metalib, the federated search system developed and sold by Ex Libris.
Just a few years prior, Cal State had licensed Metalib. We liked its knowledgebase and search capabilities, but wanted a lot more control over how the end-user interface looked and behaved. So we worked with Ex Libris to flesh-out an application programming interface for Metalib (called the X-Server), and, using that, built our own system that not only provided an improved user interface to Metalib, but also served as a platform from which we could add additional features and functionality not available in Metalib.
I called the system Xerxes, and it immediately had a major impact on our usage numbers. As we replaced the standard Metalib interface with Xerxes, we saw a huge increase in searching and the number of times users accessed the full-text of journal articles — even more than we had expected.
In 2007, we released the system under an open source license, and today over 40 institutions (mostly universities) across the globe have implemented Xerxes, with some also contributing code back to the project.
Times have changed
In that time, a lot has changed, too. A new class of library search engines – often called discovery systems – have taken the academic library market by storm, and now all but replaced federated search systems like Metalib. We like the search capabilities of these systems as well, but still want to have that extra level of control over the user interface. What can I say, we’re controlling like that.
The primary goal of Xerxes 2, then, is to provide a fully customizable and extendable interface to this new generation of commercial discovery systems, including Summon, Primo, and Ebsco Discovery.
Xerxes 2 can also serve as an interface to open source search engines like Solr and no-cost web services such as the Ebsco Integration Toolkit and the Worldcat API, which can augment (or even serve as an alternative to) commercial discovery systems. We’ll continue to use Metalib as well.
That’s a lot of systems to support. We won’t be using all of them here at Cal State, of course. But I’ve already written between 80-100% of the code needed to integrate with each of the systems mentioned above.
Frameworks
A number of new web development frameworks have also emerged and matured since I first started to build Xerxes. PHP frameworks were scarce back then, to say the least, so I just decided to roll my own home-grown framework, adding to it as I went. When Jonathan Rochkind joined the project, he improved the framework considerably, but even now it has all the usual short comings of a home-grown framework.
Along the way, we also started to use Prototype for JavaScript development, which seemed brilliant at the time, but these days is decidedly out of style.
Seems like now is as good a time as any to move to more modern frameworks like Zend Framework for PHP and jQuery for JavaScript.
From experiment to production
In fact, I’ve been working on Xerxes 2 for quite some time now. We’ve been using Xerxes as an interface to Solr, Ebsco, and Worldcat in production here at Cal State going on two years.
I originally wrote that code within the Xerxes 1.x code base, and learned quite a few lessons along the way. Now I’m focused on reworking that earlier code into a production-ready, general release using Zend Framework 2 and jQuery. You can follow my progress on Github.
More information to come
In the next few posts, I’d like to set-out three high-level design goals for the new version. I’ll then return to the technical issues of architectures and frameworks. I hope to offer up a few posts here and there on my adventures with the new Zend Framework 2, which as of January 2011 is still in beta.
