ImageMagick memory problems

I noticed my Windows development machine had slowed to a crawl recently, and I assumed it was something to do with the new plugins to convert images that are in development. Turns out it was, but not in an obvious way. Because the plugin requires ImageMagick, any EPrints process will load ImageMagick; this includes the scheduled task to run the indexer which I had installed and promptly forgotten about.

It looks like that because I had installed ImageMagick after I created this task, its environment didn't include the necessary paths for the Perl module to load correctly. It could find the Perl component, but not the XS part. Because of the way it autoloads unknown functions, this was causing an infinite recursion every time the indexer ran, which Perl eventually caught but not before it had used 2GB of my swap space and all my physical memory.

Recreating the task (in fact, just changing a property and changing it back) seems to have got rid of the problem. Maybe tasks store the path from the environment when they are created. This just proves why scheduling the indexer has to be done carefully; the Unix version has a complicated script to check that everything's running successfully, which I'm hoping Task Scheduler can duplicate under Windows.

On the positive side, the new plugins to convert images using the Perl API look to be working fine. Next stop, GhostScript—and the Windows version is getting closer to feature complete relative to Unix.

ImageMagick spoils my day

An ImageMagick design flaw means that it's unsafe to use in a batch environment where you can't trust the filename you are given. This is a problem solved a long time ago by all other Unix command line utilities, but to work around it I have to mess around with the Perl API rather than the command line.

What if you need to delete a file called -rf, or cat a file called --help? That's what the -- option is for, to tell the command that there aren't any more options, just filenames. ImageMagick interprets special characters in filenames as syntax, but there's no way to tell it not to. As far as I can tell, you can't load a file called image.jpg[23x42], even though it's a valid (though odd) filename. This kind of problem can easily lead to security problems in server applications.

It doesn't help either that the (sparse) documentation for the API says that you can read an image from a filehandle, when in fact that crashes Perl. Several hoops later I seem to have a reliable way of converting images from Windows; the next step is to hack together some EPrints plugins and see if it works for real.

New release, indexer progress

A new Windows package has now been released. This release fixes a few bugs and has a new graphical installer. Download it from http://files.eprints.org/279/.

Good progress has been made with the indexer. Metadata can now be indexed periodically, and so can full text of plain ASCII documents thanks to a bug fix. I need to write some file format plugins to convert other formats, which might involve a change in the way plugins are configured in the core. The next release (soon I hope) will have the indexer included; until then I'll post a script which can be configured manually.

New release coming

I'm preparing a new package for release, hopefully within the next week. There are compatibility bugs in the core which I'd like to have fixed first, in case they sneak into future releases; I can't commit into the core code so I need to wait until another developer gets back.

In the meantime I'm testing the indexer. No full text yet, but it works for metadata.

Indexing

I made a start on the indexer a while ago, and while it could do a single pass I haven't yet looked at how to make it a background task. It's similar to subscriptions, which are done with Windows Task Scheduler, but the Unix indexer script takes great care to interrupt the indexer if it crashes. I need to investigate how Task Scheduler works to see if it can do this.

On top of this is the problem of indexing full text. Most of the formats the Unix version can understand are converted using Unix specific tools; these need to be converted to pure Perl, Windows specific, or portable tools. I already found an module which should do the trick for HTML, and GhostScript will probably work for PS and PDF.

Status report

EPrints 3 can be installed and run under Windows. It's not yet feature complete, nor fully tested, but it's suitable for archive administrators to experiment with. If you just want to see what EPrints can do, you can try DemoPrints.

• Get the latest Windows release
• Read the installation instructions on the EPrints Wiki

What works? All the basic features are there: you can upload documents, browse and search, and create users. Full text searching is currently missing, as is anything which depends on external commands.

New releases will be made available from the EPrints Files repository.

Subversion for desktop integration

Having looked into DAV to provide desktop integration for EPrints, I concluded it wasn't up to the job. For a start, newer versions of Web Folders (the Windows DAV client) don't communicate well with Apache DAV; also making a DAV handler with any complexity requires writing C modules to plug into Apache.

I was hoping to find a DAV handler which exported the API to Perl, but not only would that still require plenty of careful coding, there don't seem to be any systems which use DAV any more. Subversion seems to be the only DAV handler in common use apart from the simple filesystem handler. On investigation though, it looks like we could simply use Subversion to provide desktop integration—and it would be powerful, easy to build into EPrints, and cross platform on both server and client.

How it would work:

• The user creates a new eprint in their EPrints work area, and adds a special type of document.
• EPrints creates a new SVN repository for that document, and gives the user the URL of the repository.
• Using a client like TortoiseSVN, the user checks out that URL into an empty working copy on their computer.
• They add files to that directory and add them to version control. When they're done working, they check in their changes, and they're synchronised with the SVN repository.
• EPrints detects that the repository has changed, and updates its version of the document.
• When the document is committed to the archive, the repository is frozen. Cloning an eprint will also clone its repository, so the user can work on an updated version of the document.

Subversion has hooks for when things in the repository change, so it can notify EPrints where appropriate, and using EPrints's user authentication shouldn't be too difficult.

Subversion, Apache, and Windows