12/19/2008

Brian and Jon installed PURLz on gould.mannlib.cornell.edu using the default database (HSQLDB, not MySQL). All members of the team have accounts with the netid portion of their username and a password supplied in email – perhaps you will have better luck than we did, or perhaps it works better with MySQL. Neither of us is familiar with HSQLDB or its command line interface.

We had difficulty doing anything, and were not even able to get to the level of the initial installation on Jon's laptop.

Among the difficulties we encountered:

• inability to find a domain again after creation
• very confusing user interface mixing modification with finding
• very frustrating inability to list anything
• conflicting documentation about when slashes are required
• very little information about whether domains inherit privileges/restrictions
• inability to make partial redirect feature work

In summary, this tool seems promising in design but is very hard to evaluate. Notes from the SVN repository history indicate work is ongoing, with bugs fixed as recently as 12/17, but we did not yet try to contact the development team.

12/1/2008

Brian and Jon installed PURLZ on Jon's Mac laptop using the PURLZ 1.2 JAR file; installation was a simple series of steps initiated by double-clicking on the Jar file.

Notes

• PURLZ 1.2 wants to run on port 8080, so we had to shut down Tomcat
• we chose the option of using MySQL, using an established user account. The database (purls) must be created for the service to start up; we specified "character set utf8" when creating the database, though nothing was said to indicate that was necessary.

Running

• run the .startPURLz script in terminal window
• go to http://localhost:8080/docs/index.html
• login

Questions

• After the protocol (http://) and host (cul.cornell.edu) sections, PURLs have a domain component of arbitrary length (e.g., /net/example), followed then by the local identifier. The software is set up to allow the specification of users allowed to create or maintain domains; if nesting domains are set up (e.g., http://cul.cornell.edu/abc/12345 and http://cul.cornell.edu/abc/def/12345), how does the software avoid conflicts over administration rights for /abc vs. /abc/def? Apparently via exact string matching; there's no notion of the /abc/def domain having any relationship to the /abc domain.

Comments

• The application has a functional and attractive interface; we were each able to create user accounts and then make domains and PURLs using those domains; the few PURLs we created interactively worked correctly.
• However, establishing a domain seems to be flaky – a number of domains were established without warning or error messages, but could not then be used to create PURLs and could not be found through the domain search tool, which reported "Search Successful" but "No Results". An option to list domains and their attributes would be very helpful

Problems with batch upload (bdc34):

I have not been able to do a batch creation of PURLs
using PURLZ 1.2. I am using curl to do an authentication and then a POST and I get a cryptic error message as a result.

$ curl -b cookies.txt -c cookies.txt -d "id=bdc34&password=test&referrer=doc/test"  --url http://corson-mac.mannlib.cornell.edu:8080/admin/login/login-submit.bsh
$ ./generateXml.py 1000 | curl -b cookies.txt -c cookies.txt  --url http://corson-mac.mannlib.cornell.edu:8080/admin/purls  -d @-

generateXml.py is a python script that generates output like:

<?xml version="1.0"?>
<purls>
  <purl id="/tld/subdomain/test0" type="301">
    <maintainers><maintainer id="bdc34"/></maintainers>
    <target url="http://example.com/test0"/>
  </purl>
</purls>