Software Requirements

Initially, it was my thought that this project was going to be able to run on any platform with a CGI capable webserver. In retrospect this is somewhat oversealous--- it means (basically) starting from scratch and trying to support all platforms. HEADACHE! Not to mention sort of silly since there are tools out there that solve the "nearly any platform" (you get what you deserve for trying to host a LIMS on a Palm Pilot ;-)). That said, I guess we have to pick out some software to get us to the stage of "building something useful."

Web Servers

When I first thought of any web server, I was thinking mostly in terms of IIS vs. Apache. I wanted to stay away with something that was intrinsic to the web server, though this may not be possible since things like reasonably strong security will be required. This is something for discussion, though there are some obvious requirements of any web server:

So far, I like Apache best. The only other real webserver contender is Microsoft IIS and while labs may already be invested in IIS technology, I think the spirit of The Open Lab in general probably rests more with Apache.

Application Environment

Ok, so this is the important bit: Selecting the application environment since we really (trust me) don't want to write our own. There are some options that come to mind (with some pros and cons off the top of my head)

Database Backend

I seriously doubt a filesystem hosted backend will cut it for a LIMS, it would probably get really unmanageable really quickly and have to replicate most of the things relational databases already do. Fortunately, databases (as longs as we have a driver) are pretty standardized these days (yay!) for SQL2 (not its real name) and most provide some bits of SQL3 (except MySQL of course). I like PostgreSQL, but there are many complaints about its bugginess. As long as we avoid vendor-specific extensions (or at least provide a generic version that can then be optimized per vendor) we should be OK here.

Application Structure


This is a big issue that I think should be considered from the beginning. There are two major issues-- frontend security and backend security. Unfortunately, I haven't yet met a database that provides file-level encryption explicitly so the backend protection may have to rely on operating system features to keep bad people away. Front end security can probably implemented much like an SSL enabled Sourceforge (or Open Lab) model with users and projects and whatnot. I worry about security for things like confidential human trials (as I'm sure every lab who works on this sort of trial must!).

Data Interchange

I like the idea of using XML as our native data interchange and providing XSLT to generate HTML (or whatever) for both the input and and output phases (basically, intermediate communication happens in XML). This is nice because conceivably 3rd party applications could then use the XML communication directly without having to parse HTML. Of course, there may be problems with things like microarray data in which each observation may consist of a several thousand element vector. Personally I think the best way to handle that is with a standard binary format (I like HDF) since you don't see people rushing off to convert JPEGs to XML, why should be convert another image format to XML? Of course, there is the issue that you'd like to assign meaning to various regons of the "image," but this is resolvable through a hybrid approach I'm sure (much like we get images on our webpages with the <IMG> tag.

Hmmm, I think I've gotten most of my major recent thoughts down now and I'm in serious need of some sleep so I'll pick this up later. Good night and, as always, your comments are greatly appreciated!
$Id: 07022001.html,v 1.1 2001/02/08 04:50:30 byronellis Exp $