The whole 2.0 meme tends to leave a bad taste in my mouth, and when used by the more — shall we say, vociferous — proponents of the principles behind the title it has been known to cause me to suffer a bad case of the dry heaves. That being said, and noting that he is certainly not one of those that cause me convulsions, I think the OpenILS/Evergreen project owes John Blyberg a very big thank you for explaining, if offhandedly and by accident, exactly what we are all about.
Quicker SuperCat update
I said coming soon, and I meant it! 😉 Here‘s the HTML output from an OpenSearch 1.1 Atom feed, rendered server side to include unAPI.
So, here’s the stack that generates that page
- The open-ils.storage OpenSRF application acts a distributed ORM for all of OpenILS’s persistent storage needs.
- We have applications called open-ils.search and open-ils.actor that give simple access to raw search methods, as well as library and user lookups (actors).
- My shiny new open-ils.supercat application provides a simpler interface to the catalog portions of the storage application
- The mod_perl module that gives open-ils.supercat a friendlier API lives here, and is slowly but surely growing an appendage that’s shaped like a generic XML feed generator.
- The html “feed” type is actually an Atom feed that has its own special toString method that pushes the Atom through a hacked up version of A9’s atom->html XSLT before it gets sent off to your browser. I added the ability to expose the unAPI links and identifiers I embed in my Atom OS output, as well as tweaked the layout a bit, but basically it’s what A9 put out under a Creative Commons license.
- Then, just to make IE happy, there’s a client side XSLT that essentially replaces the entire content of the page with a copy of itself. No, I’m not kidding. I had to do that to get this thing working in IE.
Anyway, someone with more UI skillz can come along and pretty it up a bit (let’s hope they do), but it works, and it only took about an hour — aside from my epic battle with IE — to get it working mostly the way I wanted. This bodes well, methinks, for the future of SuperCat and the write-oriented interfaces I have planned.
Now I just need to find an artist to create a great logo! Dan suggests “a super-hero cat wearing a cape, and the cape should have an iconic logo of itself on the cape… napping.” Sounds good to me. Anyone know a good artist that likes cats and OSS?
Quick SuperCat update
What its web API can do today:
- REST retrieval of bibliographic records as MARCXML, MODS, atom entry, rss item, oai_dc, srw_dc and rdf_dc, as well as OPAC redirection
- unAPI retrieval in formats above
- OpenSearch 1.0 and 1.1, and OSD generation (yes, generation — replace the dash in those URLs with title, author, subject or series to get OSDs for searches other than “keyword”); response formats are RSS 2.0, atom, MARCXML (for the completely insane), MODS and, coming soon, HTML using atom->xhtml client side XSLT, though replacing the format with a “-“, as the OSD does, returns results in RSS for version 1.0 and atom for version 1.1. There is support for limiting searches to specific libraries or local library systems within PINES, though I haven’t yet decided on the best way to expose that functionality in the OSDs — probably an extension namespace would be best.
- Patron book bag publishing in formats above, as well as an OPAC redirect (coming soon: standalone HTML via the same atom->xhtml XSLT as the OpenSearch feeds, in addition to OPAC redirect)
- oISBN
All these web services are based on the relatively simple and thin OpenSRF application, open-ils.supercat, which is a wrapper to simplify part of the open-ils.storage API, and a couple calls to the open-ils.search open-ils.actor applications. All the code was built in the little time I could steal between preparing for 10 full day meetings over the past 5 weeks, and whatever time my loving, and very forgiving, wife has allowed me on the weekends when I should have been doing yard work.
Next up
- RESTful holdings retrieval
- RESTful create and update interface for bib records
- RESTful notes interface (CRUD) for bib records and holdings
- Atom Publishing Protocol create and update interface for bib records
- More output formats for metarecords
- RESTful update/remapping interface for metarecords
- Once the unAPI paste spec starts to appear, an unAPI paste interface
… and lots more, I’m sure.