Over the last couple of years, I’ve been working on-and-off on improving the Database of Early Chesapeake Architecture. I’d recently gotten the data (again) from Swem Library and had been working on pushing it to a more open framework (it was ColdFusion + MSSQL; now Rails + Postgresql). What I wanted to be able to add in is an extensible method of citation for the various buildings and sites used (check out the work-in-progress). At the time, I tried to use RefWorks (with very little success) to handle the citations, but with the improvements to Zotero (and it’s Group ability), I thought I’d go down this road and test if this is a viable method of citation management.

I first took a look at Jeremy’s phpZotero code. The first thing I noticed is that there’s a pretty funky way that you have to construct URLs for the “API” (I think the Zotero API is more of an RSS decorator than an API, but hopefully they’re working on that). Essentially you construct a URL requests to the Zotero API server with a user ID. Unfortunately, most people don’t know their user_id, so the PHP code goes and looks this up on a different server, parses out the user_id, then constructs an HTTP request for RSS data from the API server. I kind of brace a bit at the thought of every request needing to go to two servers (multiple points of failure, speed, etc.). When I started creating a ruby wrapper for these calls, I made the object use the user_id (Integer) and not the user_name (String). Knowing folks might not know their user_id, I whipped up a quick Sinatra app on heroku to look up Zotero User ids: zotero-id-finder (source on github).

Next, I needed something to not have to use Nokogiri all the time to grab info off the Zotero server. I made a basic Gem to wrap these requests named rzotero. This is really helpful, but what I really wanted to do is add citations to ActiveRecord models a la acts_as_taggable. To that end, I started mocking up acts_as_citable which will allow you to add in citations identifiers to be used with rzotero plugin to record and display items in a collection in ActiveRecord contexts.

As a warning, all of these are in a pre-alpha-ish state and may (badly) break your code (especially since it’s lightly tested right now). As things progress, I’ll have more posts here, and over on the Scholars’ Lab site.

We have a few historic maps from our McGregor collection available through our Geoserver installation, so I looked up their layer ids and manually added them into a page with OpenLayers. Nothing fancy here, just a test to see what it looks like.

var lat, long layer;
var zoom = 10;

var lat, lon, layer;
 var zoom = 10;

 map = new OpenLayers.Map('map');
 map.addControl(new OpenLayers.Control.LayerSwitcher());

 layer1 = new OpenLayers.Layer.WMS("Map of the Southern States",
 "http://lat.lib.virginia.edu:8080/geoserver/gwc/service/wms",
 {layers: "McGregor:000003056_00011"}
 );
 layer2 = new OpenLayers.Layer.WMS("Nova Virginae tabula",
 "http://lat.lib.virginia.edu:8080/geoserver/gwc/service/wms",
 {layers: "McGregor:000003482_00011"}
 );
 layer3 = new OpenLayers.Layer.WMS("A map of the most inhabited part of Virginia",
 "http://lat.lib.virginia.edu:8080/geoserver/gwc/service/wms",
 {layers: "McGregor:000003012_st1"}
 );
 layer4 = new OpenLayers.Layer.WMS("Carte de la campagne en Virginie du Major General Mis. de la Fayette",
 "http://lat.lib.virginia.edu:8080/geoserver/gwc/service/wms",
 {layers: "McGregor:000003013_st1"}
 );
 layer5 = new OpenLayers.Layer.WMS("Carte de la campagne en Virginie du Major General Mis. de la Fayette",
 "http://lat.lib.virginia.edu:8080/geoserver/gwc/service/wms",
 {layers: "McGregor:000003019_00011"}
 );

 map.addLayer(layer1);
 map.addLayer(layer2);
 map.addLayer(layer3);
 map.addLayer(layer4);
 map.addLayer(layer5);

if(navigator.geolocation){
 navigator.geolocation.getCurrentPosition(function(position){
 lat = position.coords.latitude;
 lon = position.coords.longitude;
 map.setCenter(new OpenLayers.LonLat(lon, lat), zoom);

 var vectorLayer = new OpenLayers.Layer.Vector("Overlay");
 var feature = new OpenLayers.Feature.Vector(
 new OpenLayers.Geometry.Point(lon, lat),
 {some:'data'},
 {externalGraphic: 'http://geocoder.ca/marker.png', graphicHeight: 64, graphicWidth: 48});
 vectorLayer.addFeatures(feature);
 map.addLayer(vectorLayer);
 });
 }

map.addControl(new OpenLayers.Control.PanZoomBar());

This actually worked surprisingly well the first time I launched it. With Firefox 3.5 I tested it on my laptop. At first I wasn’t using the geowebcache we had set up, so it was a bit slow. I changed to the geowebcache WMS service and things in the browser were noticeably faster.

At lunch, I handed an iPhone to Schuyler Erle who’s first instinct was to try to drag things around and zoom-in and out. Well, there was a fail as the controls you normally use in OpenLayers were far too small to actually be useful and it just didn’t feel right.

I then attempted to add in a touchHandler function to help with the interactions from the user. I found Ross Boucher’s post “iPhone Touch Events in JavaScript” and used his code to get the sliding working:

function touchHandler(event)
{
   var touches = event.changedTouches,
   first = touches[0],
   type = "";

   switch(event.type)
   {
     case "touchstart": type = "mousedown"; break;
     case "touchmove":  type="mousemove"; break;
     case "touchend":   type="mouseup"; break;
     default: return;
 }

 // initMouseEvent(type, canBubble, cancelable, view, clickCount,
 // screenX, screenY, clientX, clientY, ctrlKey,
 // altKey, shiftKey, metaKey, button, relatedTarget);

    var simulatedEvent = document.createEvent("MouseEvent");
    simulatedEvent.initMouseEvent(type, true, true, window, 1,
    first.screenX, first.screenY,
    first.clientX, first.clientY, false,
    false, false, false, 0/*left*/, null);

    first.target.dispatchEvent(simulatedEvent);
    event.preventDefault();
 }

 document.addEventListener("touchstart", touchHandler, true);
 document.addEventListener("touchmove", touchHandler, true);
 document.addEventListener("touchend", touchHandler, true);
 document.addEventListener("touchcancel", touchHandler, true);

Now the scrolling worked, but you could no longer zoom into the map (and we want real zoom, not just making the image bigger). I haven’t found a fix for this yet, but I have to say that this is a kind of cool way of interacting with these materials.

Something I need to talk with Joe about next week making your location a query to Geonetwork and then using the top n maps returned to build this interface. It’s a little like a coverage map for your current location.

What I’m going to do here is go through the setup for building the RPM and the spec file. This should work on just about any OS that uses RPM for installing software, but this isn’t tested very extensively.

So I guess the first thing to cover is what exactly an RPM is. RPM is the Redhat Package Manager and is an implementation of a container for other files. It allows you to quickly install software, including necessary programs to run the program, provides information about the program you are installing, informs users about potential conflicts between your program and the software currently installed on the system, and provides a path to install, upgrade, and remove the software.

Now, in the case of Omeka, you don’t really need a package manager if you’re a seasoned system administrator. However, if you’re wanting to run this yourself, and you have to convince others to manage the software for you (e.g. you’re running it at an institution), have an RPM that your systems administrator installs will save a lot of headaches, especially since upgrades to the software can be integrated into scheduled maintenance with kernel and other software upgrades.

Building RPMs requires two things, the source you want to install and a specification (spec) file that tells the software what to do. You’ll need to first set your system up to have the tools to build software which you can do with a couple of lines (as the root user):

yum groupinstall "Development Tools"
yum install rpmdevtools

Next we need the directory hierarchy for building the RPMs. You can do this manually, but there’s a handy tool for helping out called rpmdev-setuptree. In the terminal, if you run this command, it will create a new folder in your home directory named “rpmbuild” with the correct directories made for you.

rpmdev-setuptree

If you want these in a different location, say omeka_rpm, you can manually create the following hierarchy:

mkdir -p ~/omeka_rpm/BUILD
mkdir -p ~/omeka_rpm/BUILDROOT
mkdir -p ~/omeka_rpm/RPMS
mkdir -p ~/omeka_rpm/SOURCES
mkdir -p ~/omeka_rpm/SPECS
mkdir -p ~/omeka_rpm/SRPMS

For our purposes, we’re really going to be dealing in the SOURCES and SPEC directories. Let’s start with the setup for the source files. First you need to get the source files from Omeka’s website and put it into your SOURCES folder. We have to do some additional work with this file since it’s packaged using zip and the RPM is expecting a gzipped tarball. The following code snip assumes you’re using the default structure from the rpmdev-setuptree command and if a release after Omeka 1.1 is the most current, you will need to update the revision numbers.

cd ~/rpmbuild/SOURCES
wget http://omeka.org/files/omeka-1.1.zip
unzip omeka-1.1.zip
mv omeka-1.1 omeka
tar -czvf omeka-1.1.tar.gz omeka

Now if take a look at the directory, you should see a new file named “omeka-1.1.tar.gz” which is in the correct format for using it to build our RPM. There are two more files we need in here, an httpd configuration file and a readme for its use. Let’s just touch these so they exist and we can come back and add content to them a little later after I discuss them.

cd ~/rpmbuild/SOURCES
touch fedora-http-conf
touch README.fedora.omeka

Ok, let’s look at the real meat of this now. You need to create an omeka.spec file in the SPECS directory. This is the script that tells the rpmbuild tool how to set up the system.

I use gedit when I have a GUI, but emacs or vi work just as well (better if you’re good at the commands).

The idea behind this setup is to set up Omeka much like other software on the system is set up. This assumes that there will be only one installation of Omeka running on the system and takes into account that MySQL may be running on another server, so only the php >= 5.2.4, httpd, php-mysql, and ImageMagick packages are required. The configuration for the database connection is set in /etc/omeka/db.ini and uses a symbolic link to the application files in /usr/share/omeka (though this isn’t quite working yet). Themes and the archive folder shouldn’t get overwritten, so those directories stay in place. An httpd configuration for omeka (which aliases “/omeka”) is added into the httpd.conf directory. Since this software does not actually need to be compiled for a processor architecture type, the build archicture is set to noarch.

Summary: Omeka web publishing software
URL: http://omeka.org
Name: omeka
Version: 1.1
Group: Application/Publishing
Release: 1%{?dist}
License: GPL
Source0: %{name}-%{version}.tar.gz
Source1: omeka-http-conf
Source2: README.fedora.omeka
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: php >= 5.2.4, httpd, php-mysql, ImageMagick
BuildArch: noarch

%description
Omeka is a free and open source collections based web-based publishing platform for scholars, librarians, archivists, museum professionals, educators, and cultural enthusiasts.

%prep
%setup -q -n omeka

%install
 mkdir -p ${RPM_BUILD_ROOT}%{_datadir}/omeka
 mkdir -p ${RPM_BUILD_ROOT}%{_sysconfdir}/omeka
 install -m 0644 -D -p %{SOURCE1} ${RPM_BUILD_ROOT}%{_sysconfdir}/httpd/conf.d/omeka.conf
 cp -pr * ${RPM_BUILD_ROOT}%{_datadir}/omeka
 #cat db.ini | sed -e "s|dirname(__FILE__).'/'|'/usr/share/omeka/!|g" > ${RPM_BUILD_ROOT}%{_sysconfdir}/omeka/db.ini
 #/bin/ln -sf ../../../etc/omeka/db.ini ${RPM_BUILD_ROOT}%{_datadir}/omeka/db.ini
 /bin/cp %{SOURCE2} ./README.fedora
 # Remove empty files for rmplint
 find ${RPM_BUILD_ROOT} -empty -exec rm -f {} \;
 # These are docs; remove and docify later
 rm -f ${RPM_BUILD_ROOT}%{_datadir}/omeka/{readme.txt,license.txt,release.txt,changelog.txt}

%clean
 rm -rf ${RPM_BUILD_ROOT}

%files
 %defattr(-,root,root,-)
 %config(noreplace) %{_sysconfdir}/httpd/conf.d/omeka.conf
 %dir %{_datadir}/omeka
 %{_datadir}/omeka/admin
 %{_datadir}/omeka/application
 %{_datadir}/omeka/archive
 %doc changelog.txt
 %config(noreplace) %{_sysconfdir}/omeka/db.ini
 %{_datadir}/omeka/index.php
 %doc license.txt
 %{_datadir}/omeka/paths.php
 %{_datadir}/omeka/install
 %{_datadir}/omeka/plugins
 %doc readme.txt
 %doc release.txt
 %{_datadir}/omeka/robots.txt
 %{_datadir}/omeka/themes
 %dir %{_sysconfdir}/omeka

%changelog
* Mon Nov 09 2009 Wayne Graham <wayne dot graham at virginia dot edu> - 1.1
- Initial build

Now we can add in the httpd configuration that will get written. Open up SOURCES/omeka-http-conf and add

Alias /omeka /var/www/omeka

<Directory /var/www/omeka>
 AllowOverride Options
</Directory>

And README.fedora.omeka

Omeka is a database driven web publishing program.

Once this package is installed, there are a few configuration items which need
to be performed before Omeka is usable.  First, you need to establish a
username and password with which to connect to your MySQL database. You also need to make both
MySQL and Omeka aware of this configuration.  Let's start by creating the database and the
username / password inside MySQL first:

 # mysql
 mysql> create database omeka;
 Query OK, 1 row affected (0.00 sec)

 mysql> grant all privileges on omeka.* to omeka identified by '1superPrivateOmekaPassword!';
 Query OK, 0 rows affected (0.00 sec)

 mysql> flush privileges;
 Query OK, 0 rows affected (0.00 sec)

 mysql> exit
 Bye
 #

Under certain curcumstances, you may need to run variations of the "grant"
command:
mysql> grant all privileges on omeka.* to omeka@localhost identified by 'omeka';
 OR
mysql> grant all privileges on omeka.* to omeka@'%' identified by 'omeka';

This has created an empty database named 'omeka', created a user named
'omeka' with a password of '1superPrivateOmekaPassword!', and given the 'omeka' user total
permission over the 'omeka' database.  Obviously, you'll want to select a
different password, and you may want to choose different database and user
names depending on your installation.  The specific values you choose are
not constrained, they simply need to be consistent between the database and the
config file.

Next, you need to edit your /var/www/omeka/db.ini file to reflect the
values you've chosen.  These values will go in the appropriate places at the
beginning of that file.

Once that's done and the database server and web server have been started,
open a web browser to http://localhost/omeka/install/ and
follow the instructions given to you on the pages you see to set up the
database tables and begin publishing your Omeka instace.

Now everything is in place. Let’s try to build this thing. Go in to the SPEC directory and build the binary for the rpm.

cd ~/rpmbuild/SPECS
rpmbuild -bb omeka.spec

This takes a while, and if you’re running this through VMWare of VirtualServer, this process will demand some pretty hefty system resources and your system will slow down.

If everything has gone correctly, you should now have a nice new RPM package named omeka-1.1.fc11.noarch.rpm in the RPMS/noarch directory. You can test it out by installing the package with

rpm -Uvh omeka-1.1.fc11.noarch.rpm

What’s Next

For packaging RPMs like this, a few more infrastructure elements need to be in place. The following outlines some of them (if you have more, leave a comment).

• Put the build files into SCM (currently only in our private SVN repo)
• Auto-install dependencies
• Set up an RPM repository to work with yum
  • Target specific Linux builds
• Automate build
• Run MySQL setup script after initial install
• Build aptitude package (using alien?)

Additional Resources

• Chapter 4. Building RPM Packages
• How To Build RPM Packages on Fedora
• RPM scriptlet recipes
• Package Naming Guidelines
• Packaging Guidelines

One thing I did try out this evening when I got home was Mapstraction. My wife has a set of data (reading test scores) that she’s been wanting to look at to see if there were neighborhoods where students were underperforming. Using a short ruby script (with the graticule gem), I geocoded addresses, calculated a median score across five reading tests, then plotted them using Mapstraction. At the top, I added some slider controls for filtering the data points, and viola, a really quick-and-dirty interactive map that lets her quickly filter ranges of scores to start looking for patterns.

Now to tweak the algorithm for generating the scores…

One of my favorite deployment tools is Capistrano. I love being able to check changes to the software to our Subversion server, and from my local machine type a simple command and update the remote source. We actually have been using this for several of our instances on our staging servers. The secret for deploying a PHP project with Capistrano is with Lee Hambley’s railsless-deploy gem. The first time you set one of these up, it’s a real pain, but you can quickly develop a template for deploying these.

I’ve been paying attention to some of the musings on Twitter regarding setting Omeka up. One of the big stumbling blocks is with MySQL. I wrote a quick helper script, and in one of my “how can I make this more beneficial” moments, I wrote a spec file for generating an rpm to install it.

I hadn’t worked on packaging in Linux for a while and forgot how painful it could be. Compounding my efforts was the fact that I was running Fedora Core to build it from VirtualBox. Normally this runs fine, but the fact that I was using rpmbuild was causing VirtualBox to eat up most of my available memory (I only have 4GB). It was just slow going because the rpmlint was taking so long.

Anyway, I have a functional rpm that can how be installed. I haven’t tested it much (read that at all), but I believe I’ve worked the bugs out of the build process. The idea here is to deploy it in a slightly different manner than you get out of the box. The RPM version creates /etc/omeka where it stores its database configuration and then defaults to placing the directory tree in /var/www/omeka. This helps in separating the configuration from the actual web application, but I’m debating with myself if everything but the archive folder should go into /usr/local/omeka.

Anyway, we’ll have an update soon, along with more code!

One of the things I never liked the way I handled was describing the basic location. At first the architectural historians wanted to use UTM coordinates. I switched to latitute/longitude and wrote some conversion code to switch between the two. I was bothered, though, that describing a “site” by a point. Obviously a site is an area that contains some number n buildings. Even worse, the points were really just the centroids of the county/city of the information that was entered as the archaeologists didn’t have have information. There had to be a better way to approach the description of this information over time.

I started working at UVa earlier this spring and one of their big pushes has been GIS in the humanities. A light went off and I saw a rather nice use of using the concepts of GIS to better describe and interact with my information. I also really wanted to migrate the information to a more open format as well as really spend some time envisioning what the application should look like.

I’ve started working on this migration and have posted it on Github. To give a brief explanation of how the application. I’m using PostGIS as the backend. On OS X, getting this ready took a bit, but I think I got it explained in the README file decently. It took a while to get the correct templates ready in PostgreSQL.

I’m using OpenLayers for interacting with the maps (through map_layers), and the spatial_adapter plugin and the GeoRuby gem.

I’m expecting there to be some refactoring of the data from MSSQL, but I think PostgreSQL will be a much better solution for my open source leanings.

I’ll try to keep this updated with my progress…at least until our development blog gets off the ground.

It took a little work, but I finally stumbled across Lee Hambley’s railsless-deploy project over on Github.

The install is pretty easy (assuming you have rubygems installed).

gem sources -a http://gems.github.com/ # make sure you have github sources installed
gem install leehambley-railsless-deploy

After this, for rails apps, you just capify the project, but this command didn’t seem to work, so I just manually added the Capfile in the root of the project directory with the snip provided on the project page:

load 'deploy' if respond_to?(:namespace) # cap2 differentiator
# Dir['vendor/plugins/*/recipes/*.rb'].each { |plugin| load(plugin) }

require 'rubygems'
require 'railsless-deploy'
load    'config/deploy'

After that, it was just a matter of using the recipes we typically use. Now, after we get the plugins we’re developing ready to be deployed, all we have to do is

cap deploy

Capistrano makes life so much easier!

Who say’s math majors can’t be funny!

#! /usr/bin/wish

wm title . "Remote Desktop Launcher"

frame .top -borderwidth 10
pack .top -side top -fill x

button .top.quit -text Quit -command exit
set but [button .top.run -text "Launch" -command Run]
pack .top.quit .top.run -side right

label .top.l -text Server: -padx 0
entry .top.cmd -width 20 -relief sunken -textvariable server
pack .top.l -side left
pack .top.cmd -side left -fill x -expand true

bind .top.cmd <Return> Run
focus .top.cmd

menubutton .mb -text Server -menu .mb.menu
pack .mb -padx 10 -pady 10

set m [menu .mb.menu -tearoff 1]
$m add radio -label server1 -variable server -value server1.address.edu -command Run
$m add radio -label server2 -variable server -value server2.address.edu -command Run
$m add radio -label server3 -variable server -value server3.address.edu -command Run
$m add radio -label server4 -variable server -value server4.address.edu -command Run
$m add radio -label server5 -variable server -value server5.address.edu -command Run

proc Run { } {
	global server
	exec rdesktop -u <user_name> -p <password> -g 1280x800 -x b $server
}

All you need to do is plugin “real” values for the server and addresses. You can also auto-login by giving values for the username and password (may also want to change the geometry of the window unless you have a big screen).

I also have bash aliases for these, but that’s a different post…

A few years ago, I had written a bunch of Sherlock plugins for searching various library catalogs. Those pretty much lay dormant until I was talking with my student worker this last semester and he got quite excited about these, and wondered if there might be a way to also search the databases the library subscribes to, and provide off-campus access to these through our proxy server. This code is in a very basic stage right now, but essentially what I did was create a database driven application in PHP that generates OpenSearch XML for various targets to search against.

Right now, this only supports HTTP GET requests (POST parameters require an additional table), but here’s the DDL:

CREATE TABLE `plugins` (
  `id` char(36) NOT NULL,
  `short_name` varchar(50) NOT NULL,
  `description` varchar(255) NOT NULL,
  `engine` varchar(25) NOT NULL,
  `image` varchar(25) NOT NULL,
  `input_encoding` varchar(10) NOT NULL,
  `url` varchar(550) NOT NULL,
  `method` varchar(4) NOT NULL default 'get',
  `proxy` tinyint(1) NOT NULL default '1',
  KEY `engine_index` (`engine`),
  KEY `short_name_index` (`short_name`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

You don’t need all of these fields for every record, and here is some useful records…

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), ' JStor', 'jstor', 'UTF-8', 'get', 1, 'http://www.jstor.org/action/doBasicSearch?Query=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'Google Your University', 'google', 'UTF-8', 'get', 1, 'http://www.google.com/univ/wm?hl=en&ie=ISO-8859-1&btnG=Google+Search&q=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'Google Scholar', 'googlescholar', 'UTF-8', 'get', 1, 'http://scholar.google.com/scholar?&hl=en&lr=&btnG=Search&q=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'Ebrary', 'ebrary', 'UTF-8', 'get', 1, 'http://site.ebrary.com/lib//Top?layout=search&nosr=1&sch=sch&frm=smp.x&p00=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'EbscoHost', 'ebsco', 'UTF-8', 'get', 1, 'http://search.ebscohost.com/login.aspx?db=aph&direct=true&bQuery=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'LexisNexis', 'lexisnexis', 'UTF-8', 'get', 1, 'http://www.lexisnexis.com/us/lnacademic/search/homesubmitForm.do');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'Proquest UMI', 'umi', 'UTF-8', 'get', 1, 'http://proquest.umi.com/pqdweb?RQT=305&FT=1&DBId=414&SQ=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'Science Direct', 'sciencedirect', 'UTF-8', 'get', 1, 'http://www.sciencedirect.com/science/quicksearch?query=');

Apparently I wrote the queries with MDB2, I’ve since moved most of my interactions to Zend Db (you should be able to write that part pretty quickly) and just dump the names of the plugins in the tableon a view:

foreach($plugins as $plugin):

    echo('<li>' . $plugin['short_name'] . ': ');
       echo(' <a href="openSearch.php?id=' . $plugin['id'] . '"><img src="images/a9.png" title="OpenSearch" /></a>'); 

        if(strlen($plugin['url']) > 0){
        	echo(' <a href="search.php?engine=' . $plugin['engine'] . '&q=regulators">test search');
            echo(' | <a href="#" title="Ref: ' . $plugin['engine'] . '" onClick="addOpenSearch(\'' . $plugin['engine'] . '\', \'gif\', \'Education\', \'' . $plugin['id'] . '\'); return false;">add</a>');
        }

        echo('</li>);

');
endforeach;

The add code is straight-forward

$result = $result[0];

$short_name = $result['short_name'];
$description = $result['description'];
$engine = $result['engine'];
$id = $result['id'];

$xml = <<<EOT
<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
xmlns:moz="http://www.mozilla.org/2006/browser/search/">
<ShortName>$short_name</ShortName>
<Description>$description</Description>
<Url type="text/html" method="get" template="http://<your_server>/plugins/proxy.php?engine=$engine&q="/>
<Contact>libsys@wm.edu</Contact>
<Image width="16" height="16">http://<your_server>/favicon.ico</Image>
<Developer>Wayne Graham</Developer>
<InputEncoding>UTF-8</InputEncoding>
<moz:SearchForm>http://<your_server>/plugins/search.php?engine=$engine</moz:SearchForm>
<moz:UpdateUrl>http://<your_server>/plugins/opensearch.php?$id</moz:UpdateUrl>
<moz:IconUpdateUrl>http://swem.wm.edu/favicon.ico</moz:IconUpdateUrl>
<moz:UpdateInterval>7</moz:UpdateInterval>
</OpenSearchDescription>
EOT;
header("Content-Type: text/xml");
echo($xml);

You just need a little JavaScript to add this in to IE and Firefox:

function addOpenSearch(name,ext,cat,pid,meth)
{
  if ((typeof window.external == "object") && ((typeof window.external.AddSearchProvider == "unknown") || (typeof window.external.AddSearchProvider == "function"))) {
    // See bugs 430058/430067/430070 for Camino
    if (((typeof window.external.AddSearchProvider == "unknown") || (window.navigator.vendor == 'Camino'))&& meth == "p") {
      alert("This plugin uses POST which is not currently supported by your browser's implementation of OpenSearch.");
    } else {
      window.external.AddSearchProvider("http:///plugins/install.php?id=" + pid);
    }
  } else {
    alert("You will need a browser which supports OpenSearch to install this plugin.");
  }
}

If I get some time soon, I’ll wrap this up into a package; rudimentary, but a decent start to your own app!