dmBridge 2.0: Halloween update
After a long beta testing period, dmBridge 1.0 was officially released in August. I've received only a small number of bug reports; whether this means that it's stable or that nobody is using it, I'm not sure. At UNLV, we are now using it in about half of our collections.
There will likely be a minor bugfix release, version 1.0.1, sometime in the next couple months, and that may be the end of the line for the 1.x branch. Work is on 2.0 is progressing, and I expect it to be released in 9-12 months. What follows is an overview of most of the key changes.
A new module subsystem will add first-class support for modules, which will enable programmatic addition of features without modifying any dmBridge code. You will be able to tap directly into, and alter, the dmBridge data store; add new HTTP API methods; modify the representations of existing methods; and add new routes in the template engine -- all via the dmBridge PHP API.
The primary motivation for the module subsystem is to facilitate a spatial query module, which will enable input, storage, querying, and retrieval of map boundary coordinates. This means that spatial searching will be possible alongside (but, sadly, not in conjunction with) term, date, and proximity searching.
Ultimately, the spatial search module will supplant our ISIS application.
Template engine and HTTP API, together again
Originally, the template engine, the HTTP API, and the Control Panel were all integrated into one component. There were a few "seemed-like-a-good-idea-at-the-time" reasons for separating them, but I was never happy with the performance of the new standalone template engine, in particular. Merging it back in will solve the performance issue, make configuration easier, and reduce the size of the code base.
The PHP API is going to change somewhat, mainly with respect to internal infrastructure stuff that can be safely ignored. All breakage will be documented.
A couple features are being removed. RDF/XML support is gone. It was useless anyway, and there is nothing I can do to improve it given the limitations of CONTENTdm®. RSS support is getting dropped as well, as there is no reason not to use Atom.
If you are not using URL rewriting, your URLs will change slightly; to be specific, the location of the "?r=" will be moved ahead by one slash. This will not affect reference URLs, which will not change and will continue to work fine.
There are a number of other changes on deck. I've moved the issue tracker to Google Code because Drupal's issue tracker is, frankly, just not very good. If you have any ideas for feature additions, feel free to report them there.