Hi Robin, everyone,
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.)
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
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
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!