should take a look at Auburn's customizations to the Voyager driver too.
were working against a 1.0RC1 era code base, but I don't think
current driver is very different.
Bellanger did most of Auburn's customizations work, but I know the
included fixes to get more accurate holding and item data for
like multi-volume serials, and possibly some handling of Voyager's
temporary locations (ILL loans, new-book shelf, ...).
also a "Mutli-voyager" driver, that wraps the Voyager driver to
with multiple ILS depending on the record-id prefix.
you move the vufind code over to github, then you could encourage
the users to just fork their customizations into their own repos there,
it would be easy for everyone to share their local code.
free for open source.
looks like Google Code also supports that kind of workflow with
- notice the "Create a Clone" button:
could probably work a similar workflow with Mercurial on sourceforge
but I think github is really geared toward this kind of workflow.
what the others think on your next dev call if you like the idea.
Thu, Apr 7, 2011 at 7:38 AM, Demian Katz <email@example.com>
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
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
Sent: Wednesday, April 06, 2011 5:32 PM
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