» Home › Forums › Project Discussion › SOPAC ›

Comparison

» Submitted by jlambertson on Thu, 09/25/2008 - 4:14pm

John B, it was good talking to you this morning. I was wondering if you had done a comparison with the Millennium module and if so, why you chose to build new modules instead of updating the Millennium module. A feature comparison or discussion of merits between these two would help me decide if I should continue to work on millennium, or switch to SOPAC.

My background for those who were not privy to our conversation:

I have spoken with janusman about updating the millennium module to Drupal 6, and have just started work on that.

John

‹ Test System / HDD requirements Thank you! ›
Submitted by jblyberg on Sat, 09/27/2008 - 2:16pm.

John,
I haven't experimented at all with Alejandro's Millennium module, so no I haven't done a comparison.

The Millennium module harvests bib records directly into Drupal as nodes which is an approach I didn't want to take. First, I don't think that is a very scalable or flexible solution because you're tied to Drupal's indexing. Second, I don't think the Drupal node is the right container for bibliographic data, especially if you want it to be portable. finally, The whole point of Locum is to build an ILS-agnostic application development platform. If I was going to put the work in to abstracting the ILS, I wanted to be able to build other apps on top of it, not just a Drupal module. Locum allows you to have a very lightweight discovery layer that can be taken advantage of by anything you'd care to build. I then extended that same approach to Insurge as the social component.

Submitted by janusman on Fri, 01/23/2009 - 4:24pm.

About comparing Millennium, SOPAC, Biblio and others... I developed the Millennium module for Drupal.

John mentioned "I don't think [importing bib records into Drupal nodes] is a very scalable or flexible solution, because you're tied to Drupal's indexing"... I don't fully understand this portion of John's comment, but I'd like to explain some of the reasons the module is why it is:

  • Importing nodes from Bib records means, you're copying/duplicating data, which implies all sorts of things, both good and bad. Here's some I could come up with:
    • Good: You gain the ability to do all the neat functionality that can already be applied to nodes via modules: creating views, flagging, RSS feeds, taxonomy, tag clouds, export to PDF and too many others to mention. Oh and without writing any code (of course, you might end up using the same amount of time configuring everything)
    • Bad: you have to somehow keep the III and Drupal copies in sync (which is not automated in the Millennium module, you have to import a list of item numbers to re-import/add/delete; it's something on my to-do list).
  • Drupal by itself can handle thousands or millions of nodes (if you have the right Apache/MySQL/PHP configuration), but I agree that Drupal's NATIVE indexing isn't great =) But there are alternatives that replace Drupal's search like Sphinx and ApacheSolr modules that, again, work on the basis of nodes. We are using the ApacheSolr module at our Library, for example.

Now, I can say that John has spent much more time thinking about these things (I started looking at Drupal for our Library inspired by his efforts at AADL).

Submitted by jblyberg on Mon, 02/02/2009 - 12:05pm.

The other major reason the SOPAC does not import bib records into Drupal is that, architecturally, I didn't want to implicitly tie SOPAC to Drupal. The whole reasoning behind Locum is to separate the discovery functions from the user interface.