You should take a look at Auburn's customizations to the Voyager driver too.
We were working against a 1.0RC1 era code base, but I don't think
the current driver is very different.
Clint Bellanger did most of Auburn's customizations work, but I know the
changes included fixes to get more accurate holding and item data for
things like multi-volume serials, and possibly some handling of Voyager's
funky temporary locations (ILL loans, new-book shelf, ...).
There's also a "Mutli-voyager" driver, that wraps the Voyager driver to
communicate with multiple ILS depending on the record-id prefix.
If you move the vufind code over to github, then you could encourage
all the users to just fork their customizations into their own repos there,
and it would be easy for everyone to share their local code.
It's free for open source.
It looks like Google Code also supports that kind of workflow with
Mercurial - notice the "Create a Clone" button:
You could probably work a similar workflow with Mercurial on sourceforge
, but I think github is really geared toward this kind of workflow.
Check what the others think on your next dev call if you like the idea.
On Thu, Apr 7, 2011 at 7:38 AM, Demian Katz <email@example.com> wrote:
On a related note, I’ve been working with Luke O’Sullivan on some Voyager driver improvements:
1.) The current Voyager class will be refactored so that it is easier to customize in object-oriented ways – the current long, complicated methods are being broken up into functional chunks, with separate methods for constructing SQL queries and processing results. This should make local customization of the driver much more maintainable – if you want to add a field somewhere or filter a value from a particular field, you can do it from a child class without having to hack the core code.
2.) Besides the local customization aspect, we’re making the base Voyager driver easier to extend so that we can create different “flavors” of the driver. The base class can remain a database-driven, Voyager6-compatible baseline… but Luke has also put together a VoyagerRestful child class that uses the new RESTful API… and we could also theoretically create a VoyagerXML child class based on the KEVEN work (though I’m not sure if it’s necessary – the RESTful approach seems more convenient).
Luke’s currently putting some finishing touches on part 1 of the list above, and I’m hoping we’ll commit it within the next week or so (stay tuned for an announcement). Part 2 is still a little further off, since it’s also tied to adding better generic support in the VuFind core for holds, recalls and renewals… but I’m hoping it will be done soon, and I’m sure Luke is willing to share his patch if you want a preview.
From: Jason Stirnaman [mailto:firstname.lastname@example.org]
Sent: Wednesday, April 06, 2011 5:32 PM
Subject: Re: [VuFind-Tech] Voyager web services examples
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
Vufind-tech mailing list