Log in

No account? Create an account

Previous Entry | Next Entry

Anyone need a new email client?

I think I may have a winner: a Java IMAP client whose design is fairly well-documented. I'll send a note off to my advisor, and set up our next meeting. My only concern is that it doesn't have the built-in captive audience that PCGen did; would anyone reading this be willing to try out my instrumented version for a couple of months, to help me gather data?

My criteria:

  1. it must run on both Solaris 8/9 (SPARC) and Linux (x86), so that I can work from either my desktop machine or my laptop (Win32 and OSX would be nice bonuses),
  2. it must be open source,
  3. it should be either something that I'll use every day, or something sufficiently recreational that I don't mind spending extra time working with it,
  4. it should be popular enough to let me find enough other users to generate enough data to work with,
  5. it needs to have gotten to a public release, but not be so worked over as to be utterly rock solid, and
  6. it would be better if it didn't duplicate the problem domains that we already have instrumented examples of: compiler tools, UML editors (and, more generally, vector-based drawing programs), or instant message clients.

The candidates:

Eclipse 2.1
Extensible multi-language IDE
Pros: The output of my project may turn out to be an Eclipse extension, so instrumenting Eclipse would be a good start at learning to hack it, and I'd be generating a lot of my own data on the fly. And tedesson's comments about the commercial possibilities of choosing Eclipse are intriguing.
Cons: samsarra is right about me needing closure, and Eclipse may be far too much unless I can get jRapture to do it for me automagically. Also, most of the other data so far comes from development tools, and adding one more seems just a bit too incestuous.
IMAP mail client
Pros: about the right size, well-documented, multithreaded, and the author is available for questions
Cons: recruiting enough users to get enough data
zax 0.9 or ZPlet
Z-Machine interpreter for 1980s (and later)-vintage text adventure games
Pros: small and easy to instrument; IF is one of my hobbies; natural audience of IF authors on rec.arts.int-fiction; could make it a "two-for-one" proposition by modifying it to also instrument the game being played
Cons: zax would need to be ported from Java 1.0; are 5000 lines of single-threaded code enough?
PCGen 5.5.2
Tabletop RPG character generation utility and gamemaster tool suite
Pros: captive audience from my D&D campaign, 50+ open bugs in SourceForge tracker,
Cons: 300k lines long, and if I'm going to go to that much effort, I'd rather spend it on Eclipse
Apache James
POP and NNTP server
Pros: can leave it running
Cons: what I really need is an IMAP server; can I get enough installations to collect enough data?
Objective-C email client
Pros: switching to a language with pointers brings in a whole extra world of potential failures, and would validate our approach's applicability to multiple languages; would include instrumenting the GnuStep version of AppKit itself, which is still pre-1.0; there are some neat tricks that I could do with the information that gcc and friends can give me
Cons: switching to a language other than Java would mean porting or reinventing much of the infrastructure that's been developed; Java might be mandatory by fiat

Bottom line: Eclipse may be too big, zax too small, and Postal just right. Eclipse and PCGen might come in handy as examples if I get jRapture working again -- they're too big to instrument by hand, but they'd be great with an automated instrumentation tool.