Everyone: You guys are fantastic. Thanks to those who have responded thus far for being so willing to share. I will be contacting y'all off-list, if you don't mind. :-)
Just wanted to tag onto Dave's response here...
> I've written a decent amount of code against Sierra, but I don't know if
> any of it amounts to an "API".
> * I've also started creating little web services with mod_perl for use
> in a
> web-application I'm working on. Examples: a script that spits back item
> information in JSON when given an item barcode, a script that spits back
> JSON list of all attached items when given a bib record number. Again
> these are mostly special purpose, but I have a notion to find ways to
> generalize them.
Yes this is basically where I am right now and where this is coming from. I've thrown together sort of a prototype app for helping us with some inventory stuff we're doing, which consists of a really quick-and-dirty web service that serves up JSON and a bootstrap/jQuery front-end. For what it is--which at this point isn't much more than a proof-of-concept--it works. But. In the coming year there are a lot of similar things we plan to do, and building out a RESTful API to serve up catalog data in particular ways seems like a logical step right now.
Julia alluded to "some things you don't want to do when you're querying the database," which is something I'm interested in talking about as well. If my experiences are anything like yours, Julia, I'm finding things just aren't indexed in ways that make it optimal for our use cases. Namely, querying on most variable field data is out of the question if you don't want multi-minute response times. It seems the only way to get this to work well will be to dump portions of the database out to an external document store / indexer. I'm primarily looking at serving up JSON at this point, so probably something like Solr or Elasticsearch. Learning from your experiences building a Sierra driver for VuFind would be quite helpful and interesting.
Francis, I'll be interested to see whether you're thinking along similar lines or if you're going a totally different direction...
> Sadly, I'm a team of one here and I'm a bit shy about the state my code
> currently in, so I haven't published it anywhere. ( Also the way I use
> locally is probably "wrong", not to mention there are probably passwords
> old commits. )
No worries! I completely understand, and I share your shyness. Believe me, I'm the last person that should judge.
> Nonetheless, I'd definitely be interested in collaborating on anything
> might benefit all Sierra users.
Cool. I really appreciate it. I guess--at this point I'm still looking at solving local needs first, but making it easy enough to extend to new use cases. Or...at the very least doing something that will provide for a good learning experience. :-) I don't know, it's still ideas.