We have several largish (> 1MB) ead instances at Columbia. One of the
approaches we use in presenting these on the web is to not have the front
end rendering code interact with entire instances, but just the data which
is needed for each particular rendering task. Our ead instances are stored
in an eXist database. The front end php code renders the pages
dynamically, pulling data from eXist by accessing a xquery script stored
in the database via eXist's REST API. This minimizes processing and the
amount of data in either in memory or in transfer.
For an example, see the display of the 3.1MB Amnesty International USA
finding aid:
http://findingaids.cul.columbia.edu/ead/nnc-rb/ldpd_6093730
Initially, the browser loads only the collection level information and
TOC, with only the top level headings for the container list and a "view
all" link to the full container list. When "view all" is clicked, the
entire container list is rendered top to bottom in sequence, so that the
user gets immediately gratified, with the rest of the page loading out of
notice. A "download/print all" button at the top of the page works
similarly, writing the entire finding aid content sequentially by
executing a series of queries on the database. Of course, the resulting
volume of data could crash a browser on some systems, but at least it does
not do so up front. We've talked about adding some sort of "Caution: Large
File" warning to the "view all" and "download/print" links to alert users
of the potential for frustration.
Speaking of frustration, we've actually encountered more trouble with
large finding aids in the production side, especially in the upload of the
instances through oXygen's eXist database connection feature (uses
XML-RPC; not recommended for anything over a couple hundred K), although
using a client to do HTTP PUT's to eXist's REST interface seems to work
better.
Hope this is helpful.
/Terry
Terry Catapano
Columbia University Libraries Digital Program
212-854-9942
[log in to unmask]
|