I was talking about a database for storing animation sequences, and another for user registration...and you zoomed off into the stratosphere of a message database! Whoa! Yeah, you could set up something like that independently of the existing system--you could read (but not modify) the XML message stores and do whatever you want with their data.

As for the topic at hand, the problem I see is indexing animation sequences in a way that makes each one unique. The image IDs are very long:

2N129837619EFF0500P1835L0M1

and there'd be an arbitrary number of them, forming a key string of arbitrary length. Say you string together 50 frames (some HazCam collections get that big) forming one very long key string--that's unwieldy in a fixed-length field, would require a blob (a.k.a. memo) field, and you can't index blobs.

As for the image-processing question, I'm pretty much against the use of animated GIFs, for a lot of reasons, not least the compression algorithm royalty problem. A lot of public domain libraries, like gd, get around the royalty problem by creating uncompressed GIFs. If you think a 50-frame animated GIF is horrifically big with compression, imagine how big it'd be without it. The way I'm doing it, I get the benefit of JPEG compression, using first-generation images created at the source by NASA. Once I add the ability to store animation sequences, we'll have a virtual equivalent to an animated GIF.

I do plan to set up some online image processing, though. I've been getting back into Java, and man, the standard Java libraries have everything you might ever need, including image processing and JPEG and other format file I/O. I set up an Apache Tomcat server to learn about Java servlets and JSP, and I like it. I'll be working more with that technology in the future, and less in the Microsoft arena.