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?
- 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),
- it must be open source,
- 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,
- it should be popular enough to let me find enough other users to generate enough data to work with,
- it needs to have gotten to a public release, but not be so worked over as to be utterly rock solid, and
- 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.
- 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.