Re: [VuFind-General] vufind + summon

[Seaman, G. <Gra...@rh...>]

Start of term now over, back to looking at vufind...

I've asked for opinions locally on removing our catalogue info from
Summon, and that idea is a non-starter for us. So, I'm carrying on
looking at using vufind as a front-end for Summon for search, and Aleph
for patron management. Which means (I think) we don't need Solr.

You said 'comment out the Solr check in index.php'. I'm running from the
latest svn version, and that isn't where the problem is in this version:
there is no explicit Solr check.

Instead, index.php creates a new UInterface object. This object in turn
creates a new searchObject, based on the searchObject factory which uses
solr by default in initSearchObject(). The only way to avoid this seems
to be to either hard-code 'Summon' into initSearchObject instead of
'solr', or to change the [Index][engine] parameter in config.ini, which
leaves me back where I was before.

Graham

-----Original Message-----
From: Demian Katz [mailto:dem...@vi...] 
Sent: 07 September 2010 13:01
To: Seaman, Graham; vuf...@li...
Subject: RE: vufind + summon

I would not recommend changing the [Index][engine] setting to use Summon
instead of Solr.  The Solr and Summon classes were not designed to be
interchangeable, so unpredictable things may happen in the future if you
assume that they are.  To avoid the "connection refused" error, I
believe the easiest fix is simply to comment out the Solr check in
index.php -- right now, we always ping Solr, but I do plan to eventually
make this smarter for situations like yours where Solr isn't necessarily
involved.

As long as Solr-specific checks are commented out, I can't think of any
reason why you couldn't call the ILS driver to get Aleph status from
within Summon -- there shouldn't be Solr dependencies there, and if
there are, there should be a way around them.  If you have trouble,
please share the specifics and hopefully I can help!

One other thing to consider -- at Villanova, we ended up keeping our
local catalog index and the Summon index separate, because we wanted
more local control over relevance and found that important catalog items
often got buried in irrelevant Summon content.  We ended up with a
two-column layout that does simultaneous Solr and Summon searches.  I
don't claim that this is necessarily the best solution...  but if it's
something you might be interested in, I'd be happy to share code.  You
can see it in action at http://library.villanova.edu/Find.

- Demian
________________________________________
From: Seaman, Graham [Gra...@rh...]
Sent: Tuesday, September 07, 2010 6:36 AM
To: vuf...@li...
Subject: [VuFind-General] vufind + summon

Hi,

I'm trying to get a basic understanding of vufind so I can adapt it to
our local situation in a way which makes it easy(ish) for us to track
future upgrades.

We are using Summon, with our local catalogue data exported from Aleph
to Summon. Ideally vufind would act as a front-end both to the Summon
search and (via the Aleph x-server) to the holding and patron details,
so that users would not need to see either the native Summon interface
or the Aleph OPAC. In this situation I assume we do not need to be
running Solr at all.

As vufind comes 'out of the box' (I'm using 1.1) the Summon driver
works, needing only a template change so that the default module/action
for the searchbox form is Summon/Search instead of Search/Results. But
the system depends on solr and gives a 'connection refused' error unless
solr is running. So I set the [Index][engine] parameter in config.ini to
Summon instead of Solr, set the SearchObject::Factory to default to the
[Index][engine] value instead of solr, and added any methods (eg.
initAdvancedFacets()) missing from SearchObject::Summon as abstract
methods to SearchObject::Base. This works for searches (I have vufind
running with solr turned off and no errors or warning message), but
fails in some of the Aleph-related tasks. For example, the way
MyResearch gets patron loan information: it seems to be written in a way
that would need more drastic surgery to make its data source
parameterizable.

Before I start hacking my way further down this route I thought it would
be a good idea to check that what I'm trying to do should be do-able and
isn't drastically out of line with the way vufind is likely to evolve...

Thanks
Graham