[OPEN-ILS-DEV] OPAC (was: Planning for Evergreen development, post 2.0)

[Dan Scott]

On Thu, Jan 20, 2011 at 12:20:30PM -0500, Sharp, Chris wrote:
> Has there been much momentum in the direction of making the OPAC more of a modular piece?  I'm just wondering if since there is talk of redevelopment if there might be an effort towards developing an API for plug-and-play OPAC/discovery layer functionality?  Basically, I'm wondering if making it possible/easy to plug in pieces like VUfind or Blacklight would be a benefit that could come out of a redesign effort.  I'm not a developer, so I'm not aware of how complex that would be.

There are a couple of ways to tackle that. One could argue that the
necessary APIs are already available - the current OPAC calls OpenSRF
APIs from JavaScript to generate all of its content, so VUFind /
Blacklight / others can use the same approach if integration at the
JavaScript level would suffice (typically for availability / holds /
account information). 

A TT2-based OPAC will call the same OpenSRF APIs, but via Perl, and as
the OPAC would probably be hosted in the same rack (if not on the exact
same server) as the rest of the Evergreen stack, all of the calls it
would make would not have the same latency issues (browser -> server ->
browser) and concurrency issues (browsers typically allow 4 concurrent
requests per host).

The best approach for a VUFind / Blacklight developer would be to invoke
those same OpenSRF APIs, but in their native programming language.
Unfortunately, PHP and Ruby bindings for OpenSRF (and the interesting
bits of Evergreen, particularly the fieldmapper) do not currently exist.

One of the tacks I had been taking in the social work was to enable
results to be returned as either Activity Streams XML or plain HTML. If
we take a similar approach with the new OPAC and enable a given URL to
resolve as either plain HTML or JSON, then that could make integration
much simpler for other discovery layers. For example (making up a
template URL rather than the current primarily GET param-based
approach):

curl http://localhost/eg/opac/record/2

as HTML would show the usual human-oriented display of a record;

curl -H "Accept: application/json" http://localhost/eg/opac/record/2

could return a JSON representation of the record (one section with
biblio details, one section with holdings);

... and then the caller could take the JSON representation and easily
pull out the pieces of interest to munge into their discovery layer
display.

And assuming we merge our efforts on the new OPAC & social front, the
JSON could include a section with reviews / ratings / other social data,
and...

curl -H "Accept: application/xml" http://localhost/eg/opac/record/2

could return an Activity Streams representation of the record (including
the reviews / ratings / other social data).

When I was working on the Activity Streams functionality, I found that
getting the URLs right and making as much of the data URL-addressable as
possible (e.g. individual reviews, but we can extend that to individual
copies for example) was the hardest and at the same time the most
rewarding part. 

> That question aside, I think an optimized built-in OPAC would be a big
> improvement.

For sure.