Oct 8 2008

LibraryFind 0.8.5.2 available

LibraryFind 0.8.5.2 has officially been tagged and posted to the libraryfind.org website.  You can get the tarball here: http://libraryfind.org/release-0.8.5.2.tar.gz.  This release has admittedly been a long time coming.  What’s held it up?  Well, primarily work that we were doing for people interested in using LibraryFind outside of the public view.  Of course, the result of some of that work has been integrated into the 0.8.5.2 build which I think will make the overall application better and more reliable. 

The other thing that slowed the release of 0.8.5.2 has been the parallel development of 0.9.0.  The 0.9.0 branch will represent a different direction in the UI — in that the UI will be much more responsive to users, allow users to stop a query at any point and retrieve present results, see queries and search status, etc.  Because the 0.9.0 represented, in many ways, a redesign of the UI framework, the time that it took to make it all work together took more time as well.  Fortunately, at this point, the 0.9.0 test branch is also feature complete, so the turn around between the 0.8.5.2 and the 0.9.0 builds should be a short one.

–TR


Sep 3 2008

LibraryFind notes & stuff

So, I just wanted to update folks on some LibraryFind work.  0.8.5.1 is pretty much ready to go.  The only things that I’ve been waiting on are changes to two core components — the oai.gem and the sru gem.  So, I added libxml support to the sru gem (both support for the current and past libxml branches).  This has been done.  This change should allow ruby sru processing to be done much faster (especially large sets).  When I added libxml support to the oai gem, performance went up by 4-800%.  I’m expecting that parsing large datasets will see similar speed increases.  The beauty of the changes is that they should be transparent to the user.  Prior to the change, this is how you would make a search_retrieve request:

#Example search_retrieve request.
require ‘rubygems’
require ’sru’

#An iterator for search results which allows you to do stuff like:

client = SRU::Client.new ‘http://z3950.loc.gov:7090/voyager’
for record in client.search_retrieve(’”title=building digital libraries”‘)
   puts record
end

puts “\n\n”
puts “finished”

For users wanting to continue to use rexml as your processor, this syntax will still work.  For users wanting to use the libxml parser, all you need to do is add an optional parameter to the client object:

#Example search_retrieve request.
require ‘rubygems’
require ’sru’

#An iterator for search results which allows you to do stuff like:

client = SRU::Client.new ‘http://z3950.loc.gov:7090/voyager’,:parser=>’libxml’
for record in client.search_retrieve(’”title=building digital libraries”‘)
   puts record
end

puts “\n\n”
puts “finished”

That’s it.  Now, rather than returning a REXML::Document reference for each record, the program will return a LibXML::XML::Node reference. 

Internally, I removed the protected xpath processing functions and borrowed the xpath module I created for the oai gem.  Now, all xpath processing is pushed through this module, allowing the gem to use the appropriate parsing calls based on the document.class value.  Within LibraryFind, I’m adding metadata handlers to work with MARCXML and Dublin Core data.  At some point, I might migrate this code into the sru gem to include two predefined metadata handlers so that you can retrieve metadata either as the raw data object or as a formatted object.

I’ve also finished work on the oai gem.  I checked in some changes about a week ago (adding support for the current version of libxml), but will be checking in an additional update this weekend (after a little testing).  The changes add some additional unit tests, as well as corrects the oai gems providers functionality to fix the dates generated by the oai output.  The dates needed to be updated to use the utc.xmlschema format (rather than the localtime format).  This has been done and now oai data generated by the provider class is validating again.  It’s currently passing all unit tests and once I confirm it’s functionality is some real world applications here at OSU, I’ll update the code and push the changes for download. 

Once these components are downloaded, LibraryFind 0.8.5.1 should will be ready to package and ship.  This will be an intermediate release, as 0.9.0 is also finished needing only formal testing.  So, once 0.8.5.1 is put to bed, I’m hoping to have only about a month, month and a half between the 0.9.0 release, which will bring with it a much more interactive UI.

–TR


Aug 8 2008

LibraryFind Changes a coming

It’s been a little while since the public LibraryFind code repository has been changed.  This is mostly due to some work being done privately with a number of partners to tweak the software for use within some larger local implementation.  Over this next weekend, I’m going to be working on moving many of these changes into the code base, as well as migrating the current codebases (first, 0.8.5) to utilize rails 2.1.  I’m anticipating getting this process finished this weekend, but will post here when the 0.8.5.1 branch has been updated, and then will get to work migrating the necessary changes into the 0.9.0 branch.

 

–TR


Mar 20 2008

Libraryfind 0.8.5 rc1

Since Code4Lib, we’ve made a few significant changes to the 0.8.5 alpha tag.  Many of these are related to issues due to migrating to Rails 2.0, including issues with some pagination, changes to how rails handles posted data and then my favorite, issues with Rails defaulting to ActiveRecord caching (something that’s generally desireable, but causes issues within a threaded environment).  These fixes have all been wrapped up and pushed out via the svn: Branch 0.8.5 RC1.

There are one or two odds and ends that I’m interested in tightening up before we set this loose, but should be soon.

–TR


Dec 3 2007

LibraryFind 0.8.5: threading and XSLT and REST, Oh my

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


Nov 29 2007

LibraryFind and Mobile Services

One of the things I was really impressed with while attending DLF was the presentation on the lightweight web platform being built at NCSU.  Leveraging their endeca catalog, the folks at NCSU have been able to produce a set of REST-based api for querying the catalog.  With those services, they’ve designed a mobile interface and a google widgets interface to their catalog.  It’s a good idea — one that I’m working on moving into LF.  LibraryFind already supports a SOAP-based API (which is actually my preference), but I’m running into more and more cases where a light-weight rest-based api would be nice.  Fortunately, ruby/rails makes this possible. 

Anyway, in the spirit of looking at building client services ontop of libraryfind, I’ve created a quick facebook app using libraryfind.  Whether we’ll actually use it (or be able to contribute it to the facebook app list — who knows), but it was actually pretty simple to put together.  Here’s a couple of quick screenshots (you’ll notice I’m using the iframe option — mostly because I was getting annoyed while testing the app getting dropped out of facebook.  This way, the user stays in facebook, but can query the service.

Facebook LibraryFind app Front:

image

Facebook LibraryFind Search/Results:

image

 

At this point, the app is just rendering LF in the iframe, though I imagine that an interface developed for mobile users would also work best within this environment.  I guess time (and usability testing) will tell (if there is even any interest in having something like this at all).

–TR

Technorati Tags: ,

Nov 17 2007

LibraryFind 0.8.4 upcoming changes

At some point, I’ll likely move this to the LibraryFind blog.  I just realized that I couldn’t remember my login information to post to the blog — so, I’ll post here.

I’m not exactly sure if the UI changes will be made in 0.8.4 to incorporate the new spawning/pinging (I think that they will), but the next version of LibraryFind will include an extended set of API that will allow users to develop UI interfaces that allow searches to be done independent of the UI.  This was done using a spawn plugin (you can find it on rubyforge or linked in lf via svn:externals), the creation of a jobs queue, and changes in a lot of the backend server components to make this all work.  I’ve just checked into the 0.8.4-ping branch (and soon into trunk once I’ve finished testing and create some unit tests) all the code necessary to make this work.  This requires the following changes to the LF codebase:

  1. meta_search.rb refactor:  In order for this to work, I’ve had to move the cache checking code out of this file and move it into a more abstracted “connector” class.  The connector classes needed to be modified to support the new pinging functionality

  2. New models: job_query.rb, job_item.rb, cache_search_session.rb, cached_search.rb, oai_search_class.rb, z3950_search_class.rb, opensearch_search_class.rb

  3. API file changes: query_api.rb

  4. Controller changes: meta_search.rb, query_conntroller.rb, dispatch.rb, record_set.rb

  5. Migration changes: New migration has been added — 025_create_job_queues.rb

  6. Changes to the environment.rb file (these will be in the environment.rb.example file)

New SOAP API elements:

  • GetJobRecord (Queries the result set for a single job, returns the array of records)
  • GetJobsRecords(Queries the record sets for an array of jobs, returns the array of records)
  • SearchAsync (Returns an array of job ids, works like search)
  • SimpleSearchAsync (Returns an array of job ids, works like simple search)
  • CheckJobStatus (Returns a JobItem object for a single job)
  • CheckJobsStatus (Returns an array of JobItem objects for an array of jobs)

The presumed workflow with the api is as follows:

  1. Client will utilize the SearchAsync (or SimpleSearchAsync) API to initiate the search.  This will return an array of job ids.
  2. Client will periodically ping the server, using CheckJobStatus (or CheckJobsStatus) for a list of jobs and their status.  Status is an enumeration.  -1 == error, 0 == finished/idle, 1 == searching
  3. Client will retrieve records once items have been processed by calling GetJobRecord (or GetJobsRecords) for the array of records.

With this finished, I’ve completed pretty much all the current tags waiting for 0.8.4 and will be focusing on one additional enhancement that I’d like to see in 0.8.4 (if we can finish and test) or 0.8.5 — that being the addition of a REST-based XML api as well.  While I actually prefer the SOAP stack for some development, I would like to provide a REST-based api for more lightweight clients.

Anyway — that’s the news for now.

–TR


Nov 16 2007

LibraryFind 0.8.3 tagged

Jeremy I’m sure will get the tgz version of the file up and ready on the LF site soon, but the 0.8.3 instance of libraryfind has been tagged.  If you are interested in finding out more about libraryfind, see: http://www.libraryfind.org.

 

–TR


Sep 7 2007

LibraryFind 0.8.2

I still have to create the tar-ball, but I’ve officially tagged 0.8.2.  This includes a number of fixes, as well as the inclusion of the smart_session_store plugin.  This plugin was necessary to solve some sessioning issues caused by timing, and our Ajax implementation. 

–TR


Aug 5 2007

I hate SUTRS

I’ve been profiling CSA for LibraryFind and have had to deal with the SUTRS format.  I hate it.  How this is easier than MARC or XML…Anyway, it just had to be said. :)

 

–TR