Access2007 Hackfest
Gabriel Farrell
recall the joy that was hackfest at this late date.
So this is my report from the "Refactoring Fac-Back-OPAC" Access2007
Hackfest group, which included Mark Phillips, Birkin Dianna, Harish
Maringanti, and me. Oh, and Dan Scott on the periphery (about 5 feet
away in the Evergreen group).
1. Intro
My main reason for suggesting the hackfest project was to get some
work done on the django part of the codebase. Specifically, I wanted
to create a branch ("new_helios") and start with a clean django
project and app there.
2, Solrtalk
We talked about splitting up the code into separate apps. An app that
serves as an intermediary to solr, tentatively named "solrtalk", was
discussed. Queries would be passed to solrtalk, it would parse them
and possibly remove or alter offensive bits (those that cause a solr
error dump), then pass it to solr. The response from solr would be
passed along untouched.
The reasons for this are that the settings for solr could be stored in
that app (more on that in 2.) and that it created a cleaner connection
to solr, allowing cleaner code in other apps and making it easier to
substitute something else for solr, should one want to.
The reasons against are that solrtalk simply creates another layer
without adding much in the way of ease or functionality. We could
achieve much of the same functionality and a clean connection by
dropping solr.py into the "discovery" app directory
(http://svn.apache.org/repos/asf/lucene/solr/trunk/client/python/solr.py,
see also https://issues.apache.org/jira/browse/SOLR-216).
3. Settings
We also talked about splitting the settings to allow for local
settings (see http://code.djangoproject.com/wiki/SplitSettings) and
application-specific settings (see
http://groups.google.com/group/django-developers/browse_frm/thread/5dba01e46461fad).
My opinion is that as much as possible should be collected into the
one settings file. It's easier to find stuff in one file than spread
out among app directories. Also, regarding local settings, I've found
that with other projects (see http://fruct.us/dspace_svn) it's
actually easier to overwrite files, then on svn up deal with
conflicts, if any, than to maintain semi-overlapping layers of config
files.
4. New Applications
I mentioned the "discovery" app. This app covers everything at the
discovery layer, i.e. a search box and a results page. This, to me,
is the more interesting part of the project, so I wanted to split it
out to better focus on it.
The item-level display is handled in an app called "catalog", though
it might be better to generalize it into "item_display" or something
similar.
Due to the myriad things I'll be stuffing into our Solr index, and the
myriad ways of getting them in there, I'm not as interested in the
"indexer" part of Solr, though I think it will continue to be useful
to provide a way for libraries with MARC dumps to easily test out the
project. Rather than make it a big part of the project, however, I'm
tempted to say in the README, "Run this yaz-marcdump command on the
data to turn it into utf-8 MARCXML, then xsltproc it against this
XSLT, then run this Solr command."
5. Django Flare?
It was noted at one point that some of my efforts to generalize the
project seemed to point it in the direction of a Django-based Flare
(http://wiki.apache.org/solr/Flare). While I will probably reuse some
of what I learn here about relating Django to Solr, I'm not sure this
project would be as useful if it became too general. It's really not
that hard to use Solr from Django, so I think it's of more benefit if
FBO/Helios can serve as an example of what can be done, without trying
to cover every potential Django/Solr use case.
That said, I may attempt to generalize a little bit and expand the
schema some to allow for other types of library items (IR stuff, web
site resources) in the index. If this ends up breaking or overly
complicating the OPAC-replacement role of FBO/Helios, I'll save it for
another project.
Gabe
ps I've copied the slides from the hackfest to
http://fruct.us/slides/access2007/fbo_hackfest.html
Mike Beccaria
Gabriel Farrell
On Oct 22, 1:23 pm, "Mike Beccaria" <mikebecca...@gmail.com> wrote:
> Wow! How excited am I! This is so cool Gabe! I can't wait to see the output.
> I'd contribute, but I'd probably break the thing (I know I would). I'm doing
> a presentation on November 8th at the CODI conference in Pittsburgh about
> how to get fac-back-opac running on a windows machine from start to finish.
> Letting folks know that changes are in the works to make it better is great
> news! Thanks for everyone's hard work!
>
> Mike
>
Glad to see your excitement, Mike. Feel free to pitch in -- sometimes
breaking a thing is the only way to make it better. It can also be a
good part of figuring out how it works.
Good luck on the presentation. I'm hoping some of these changes will
make installation a bit easier.
Gabe
> > see alsohttps://issues.apache.org/jira/browse/SOLR-216).
>
> > 3. Settings
>
> > We also talked about splitting the settings to allow for local
> > settings (seehttp://code.djangoproject.com/wiki/SplitSettings) and
> > application-specific settings (see
>
> >http://groups.google.com/group/django-developers/browse_frm/thread/5d...
> > ).
> > My opinion is that as much as possible should be collected into the
> > one settings file. It's easier to find stuff in one file than spread
> > out among app directories. Also, regarding local settings, I've found
> > that with other projects (seehttp://fruct.us/dspace_svn) it's