At present, I’m wrapping up the back-end changes to what will be LibraryFind 0.8.5. Yup, we’ll be skipping 0.8.4 in part because I’d like the release point to represent the broadness of the changes being made. In fact, had the UI portions of the code been modified to completely support the new back-end searching, we’d likely jump the release point to 0.9.
So what changes are coming in the back-end side of LibraryFind:
Minor Changes:
- SRU support: I’ve added a class to support SRU searching
- Connector class refactoring — I’ve made these a little more abstract and created them as a model. Should continue to simplify the creation of new connector types when necessary.
- OpenURL resolution becoming optional: While LibraryFind has been designed to integrate directly with some OpenURL services to provide inline resolution of items prior to showing them to the users — this does add a barrier for folks wanting to test. So, I’ve made this optional. If you don’t enable OpenURL resolution, it will just generate links to the resource if possible.
- Finally gotten rid of a warning message that was being thrown each time I processed a collection of Record objects. When the value of the record objects property was nil, it would throw a warning. It was causing any problems with rendering or searching, but it was filling the error logs with unnecessary information.
- Other optimizations (see trac for a full list)
Major Changes:
- Expanding the current API to include an asynchronous set of searching tools. Currently, LibraryFind utilizes Ruby’s Thread classes to initialize the various searches that it needs to run to retrieve a set of results. Unfortunately, while this process does thread the various searches, it still requires a primary thread that holds an HTTP connection open until all the threads have finished running. So, in an effort to make searching more user friendly (and faster), I’ve made use of the spawn plug-in. This was nice because it supports both ruby’s threads as well as forking of processes. Add a job queue, some additional models and there you have it. The 0.8.5 UI has been refactored to make use of the new API — but you will not see any changes to how the results are presented. In the future, this will change.
- REST API. LibraryFind has supported the full SOAP stack since its inception. This is in part because I prefer working with SOAP and it worked. Well, in order to support more light-weight search clients against LibraryFind, I’ve started adding a REST-based protocol. At present, the only API method currently emulated is the search function. However, I’m planning on including support for our Asynchronous search and Collection related API. Hopefully, this will provide one more point for integration.
- XSLT support: In addition to providing a REST based API, these queries will also accept an XSLT file which can be used to transform data on the fly. This will allow for the development of UIs through the simple creation of an XSLT file.
Anyway, that’s what’s on the menu for 0.8.5 at the moment. My guess is that we’ll be doing a feature freeze shortly and start the quality control process. So things are starting to move quickly.
–TR