2010/1/21 robin <robin.is
...@gmail.com>:
> Hey there,
> I'm thinking that in order to stay true to the standalone philosophy
> of Syrup, in other words, to put interoperability front and center
> (and I don't have any problem with that), all we really need to do is
> combine the best of the original schema with the one I did, and run it
> all in sqlite, as a native Django app. complete with Django admin
> interfaces etc. Then all that's required is the creation of an
> interface that allows different ILS's to talk to it. Because of it's
> flexibility and simplicity (not just cause it's used heavily by
> Evergreen -- but that is a happy accident) I'm going to suggest a JSON
> service.
> Python has a JSON library that can be used to send and receive
> messages, this could be built into Syrup. On the other end, we simply
> create a javascript library that wraps JSON calls in simple helper
> functions like retrieve_item_by_isbn() which returns a JSON object
> that the local sys admin (whomever that is) can work with and make
> talk to their respective ILS (whatever that is). If necessary, we
> could write simple libraries in perl and python too so a local sys
> admin has their choice of language to work in. I don't think the
> libraries would have to be very complicated.
> What does the list think?
I don't have any allegiance to Syrup as a standalone application; I
just want a reserves system that we can actually use. I expressed my
concerns about the loosely-coupled approach to Graham and Art almost a
year ago, but set them aside then because I was convinced that we
would at least have a usable reserves system and I wasn't in a
position to contribute any code to the effort. However, I still have
reservations (heh) about building reserves as an independent app with
its own data store.
* A separate data store segregates data that could be extremely
useful to the rest of Evergreen in an academic context (instructor /
course / class mappings) into a separate database.
* A separate data store complicates reporting because there's no way
to use the Evergreen reporter module against the reserves data store.
Reporting is very much on my mind at the moment. One of the reports I
was recently asked to write was a count of the number of reserve
transactions, by course ID. I can do that in Evergreen today because
we're using bookbags to group the reserve items and can determine
whether an item was on reserve by its circulation modifier, but it's
tenuous. The only way that I could do that in the current Syrup model
would be to periodically suck the data in from the Django database
into a side table in the Evergreen database and craft custom SQL
queries to link in the pertinent data. Not fun.
At this point, I'm also concerned that we're also using technology
that doesn't fit with the rest of Evergreen: jQuery instead of Dojo,
Django-ORM instead of cstore / pcrud, SQLite instead of PostgreSQL,
Python instead of Perl or C. That broadens the surface for
vulnerabilities (umpteen more base modules to update) and reduces the
ability to reuse skills between Evergreen core and Syrup. Ironically,
the combination of not being integrated & foreign technology (PHP &
MySQL) was pretty much the rationale for not adopting and contributing
to the ReservesDirect community in the first place (which no longer
has any plans for continued development - RIP).
Luckily, the Evergreen SIP and Z39.50 interfaces that were extremely
weak bases to build on back when Syrup started, and that were chosen
as the point of integration with Evergreen, have firmed up
considerably since then (yes - we now accept and handle queries with
non-ASCII characters properly!). So there's that. But they're still
limited compared than their native Evergreen counterparts.
Robin - to make your proposal more concrete, can you model how a
typical reserves task would send and receive data between Syrup and
Evergreen? For example, a professor wants to place an item on reserve
for their course, starting next term. How do they do this, and how
does the item get from wherever it currently is to the reserves
location at the appropriate time, with a new temporary circulation
modifier, and with a new temporary call number? And then, when the
course is done, how does it get back to the correct location with the
previous circ modifier and call number? I think working through
something like this, with a description of the actions humans have to
take as well as identifying which OpenSRF calls we would have to make
(and where data is changing in both Syrup and Evergreen), would be
helpful.
--
Dan Scott
Laurentian University
