Syrup -- the next OpenSRF app?
robin
think we've got the database structures sorted out, we just need to
combine the best of what is in Syrup with the RFC based schema; we've
got an administrative interface to hang the core functionality off of
(Django); so the last remaining *big* problem (in my mind) is: how do
we make Syrup talk to other systems?
The problem is how do you anticipate what Syrup will have to inter-
operate with? Universities don't really have many standards in terms
of managing student and course data and the closest although ILS
software standardize on MARC records, but user interfaces and other
admin aspects (permissions etc) are completely different from product
to product. In my mind this is the major issue. If Syrup is to be a
standalone product, then how it talks to other systems is a pivotal
issue.
From my point of view, programming to an unknown variable is difficult
in the extreme (or impossible). At the very least it's impossible to
do well. So I think we need to build Syrup as a completely self
contained app with it's own database back-end fronted by Django and
then provide a set of interfaces that allow local system admins to
glue it to their own course / student management systems and their
local ILS. It might seem like we're passing the buck by making
interoperabilty the local sys admin's problem, but they're the only
ones who can solve that problem well: they'll know how Syrup works and
they'll know how their local systems work -- no unknown variables.
So what do we build the interface out of? OpenSRF comes to mind.
Graham has already posted on this and I think there's a lot of merit
here. First off, OpenSRF and Open-ILS are different things -- you
don't need to run Evergreen to use OpenSRF. OpenSRF is a framework
that Open-ILS is built on. This of course makes using OpenSRF very
attractive to Evergreen libraries because of the high level of
integration possible. But it seems like a good choice for other
library's too: 1) it's based on perl which is a really popular and
common language in the library community which means it should be
fairly easy for local systems librarians to strap it to other
systems; 2) there are bindings for python, which is what makes Django
go; 3) it would be interesting to try building another app on top of
OpenSRF. As far as I know, Open-ILS is currently the only app that
uses the OpenSRF framework. Going this way has the potential to get
the interest of the broader Evergreen community to help develop and
maintain it.
Thoughts? If there's some consensus on this list for this, I'll post
this message or a variation of it on the open-ils discussion lists to
see what happens.
Robin
Graham Fawcett
Sorry for chiming in late. I was on vacation last week with my family
(under strict orders to stay away from all computers!).
Yes, agreed. In Syrup-so-far, we've got a "layered" API for talking to
campus (registrarial) systems -- layered in the sense that it respects
that some institutions will be capable of exposing more information to
Syrup than others can. One library might have access to detailed class
lists; another might only know of course offerings in the term; still
others only the general list of all courses in the academic calendar,
but no semesterly details.
We can use any and all of this information in Syrup: the more the
better, but even those with limited campus information should be able
to take advantage of it. Hence the layering: when implementing the
campus API, we demand a few minimums, and encourage the implementation
of optional (but useful) methods where available. (Of course, we can't
spin gold from flax -- a limited implementation will mean that the
Syrup instance is also limited in many regards.)
> So what do we build the interface out of? OpenSRF comes to mind.
> Graham has already posted on this and I think there's a lot of merit
> here. First off, OpenSRF and Open-ILS are different things -- you
> don't need to run Evergreen to use OpenSRF. OpenSRF is a framework
> that Open-ILS is built on. This of course makes using OpenSRF very
> attractive to Evergreen libraries because of the high level of
> integration possible. But it seems like a good choice for other
> library's too: 1) it's based on perl which is a really popular and
> common language in the library community which means it should be
> fairly easy for local systems librarians to strap it to other
> systems; 2) there are bindings for python, which is what makes Django
> go; 3) it would be interesting to try building another app on top of
> OpenSRF. As far as I know, Open-ILS is currently the only app that
> uses the OpenSRF framework. Going this way has the potential to get
> the interest of the broader Evergreen community to help develop and
> maintain it.
This is a good summary of our last conversation with Art. I'd like to
clarify one thing: we haven't proposed (at least not yet!) to expose
any Syrup-internal information through an OpenSRF service. Rather,
we're proposing to extract an important subsystem of Syrup -- the
campus integration interface -- and implement that system as a
standalone OpenSRF service. This brings a number of benefits not only
to Syrup (esp. the dual benefits of shrinking the codebase, and
sharing a larger developer audience!), but hopefully it will benefit
the Evergreen community as well. Having campus/registrar information
available through OpenSRF might prove very useful in a number of other
applications.
So far, Syrup has some fairly specific (though fairly obvious) campus
integration requirements. I'd like to take the Syrup use-cases as a
starting point, and prepare a draft for a general "OpenSRF campus
information service". My hope is that we'd establish a "version 1.0"
spec rather quickly -- one that satisfies Syrup's requirements -- but
also enage the Evergreen community at large to comment on the spec,
and consider how they might want to extend or refine it for non-Syrup
use.
It's important to remember is that we're specifying the OpenSRF-facing
interface of the service: the implementation details are *highly*
specific to the implementing institution. You might implement the
interface using Perl to communicate with your Active Directory server,
or using Python to read from your Oracle database; but on the OpenSRF
side we only see language-neutral method calls and data structures,
and that's where we want a clear specification.
I plan to write a first reference implementation in Python along with
the draft, and probably also an LDAP-based Python implementation which
would be useful to our campus. But the spec is the thing that matters
most, IMHO, and will be of widest interest. If anyone is interested in
working on the draft, I'd love to hear from you. I will try to get an
initial document ready within the next day or two.
> Thoughts? If there's some consensus on this list for this, I'll post
> this message or a variation of it on the open-ils discussion lists to
> see what happens.
+1 on cross-posting, Robin. I hope there will be some interest!
Best,
Graham