Terry’s Worklog

While adding REST support for Libraryfind, I found that I wanted to provide an output in XML, but that could also provide HTML if an XSLT was attached.  In Rails, generating XML files is actually pretty easy.  In Rails, output is specified in views.  HTML views are created using a .rhtml extension, while xml views are created using a .rxml extension (at least, until Rails 2.0 when they are to change). 

Anyway, we use libxml for XML processing of large XML documents (since I just have never found REXML up to the task) and was happy to find a gem based on libxml that provides XSLT support as well.  The libxslt-ruby gem provides a very simplified method for doing XSLT processing in ruby.  In the .rxml file, I add the following code:

if params[:xslt] != nil
@headers["Content-Type"] = "text/html"

# Parse to create a stylesheet, then apply.
s = xslt.parse
s.apply
return s.to_s
else
return _lxml
end

Simple and no fuss.  The XML::XSLT.file function can take a physical or remote file location.  To parse the file, you must pass into XML::XSLT.doc a reference to a XML::Document object.  Since libxml doesn’t provide a function to deal with xml data directly (it assumes that you are loading XML via a file), you simply need to use the included XML Parser object to create an XML::Document object dynamically.  Anyway, I’m finding that this works really well.

–TR

I was installing LibraryFind on a server at Willamette University the other day for testing purposes, and ran into something that I had never seen before.  While setting up the dependencies on the test server, I found that the current version of ruby found in the distro’s YUM repository was old (1.8.5), so I decided to download and compile ruby from source.  So, here’s the steps that I followed:

1. Downloaded Ruby 1.8.6 (current patchset)
2. Compiled Ruby (no errors)
3. Downloaded Rubygems
4. Ran setup…which was successful
5. Using Rubygem, I tried to install Rails and this is where I ran into problems.  The download starts and then throws the following error:
   ERROR:  While executing gem … (Gem::Exception)
       SSL is not installed on this system

So, I made sure openssl and the openssl-devel packages were installed on the machine.  Well, they were.  After digging around on the web, I couldn’t find anything that helped — however, I did find an email message from a long time back when we were compiling ruby to work with mysql and had to compile from source.  To make it work, we had to go into the ruby ext folder in the source and compile some files directly.  So, I figured I’d give it a try for openssl and it worked.  So, here’s the steps I followed:

1. Navigate to ext/openssl in the ruby source folder.
2. Once there, you run the following:

ruby extconf.rb
make
make install

3. After running the install, you can ensure that ruby can “see” the openssl information by running the following from the command-prompt:
   >>irb
   >>require ‘openssl’
   If everything is setup right, you will see the following: =>true.

–TR

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:

1. SRU support: I’ve added a class to support SRU searching
2. 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.
3. 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.
4. 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.
5. Other optimizations (see trac for a full list)

Major Changes:

1. 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.
2. 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.
3. 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