[3024] in Release_7.7_team
Evaluation of Mahogany mail client
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Oct 19 15:35:59 2001
Date: Fri, 19 Oct 2001 15:35:54 -0400
Message-Id: <200110191935.PAA22178@error-messages.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: aui@mit.edu, release-team@mit.edu
I've finished evaluating Mahogany. I wrote it as a web page, but here
is a lynx dump (edited a bit) for archival and convenience. In
general, Mahogany seems adequate but uninspiring.
Mahogany Evaluation Report
Mahogany is a C++ mail client written using the wxWindows
cross-platform GUI library. Fortunately, this GUI library preserves
the native look and feel on all platforms, so to the user Mahogany
looks like any other gtk application. Both Mahogany and wxWindows are
sourceforge projects. The Mahogany project appears to be about two
years old, and is currently at version 0.63. The last release was in
June 2001; a brief look at the CVS repository suggests that
development is active but not especially speedy, and is currently
dominated by one contributor.
Mahogany does not try to support krb4 or krb5 IMAP, but its IMAP
support uses the c-client library from the University of
Washington--the same code used by pine. Thus, there is krb5 code built
in and krb4 code available separately, so it was only necessary to
convince the build system to use it. I was able to build on our
experience with Pine in order to do so, and had no great difficulty.
Incorporating wxWindows and Mahogany into the release would probably
not be difficult. The build system had only minor flaws (e.g. the
--with-wx-prefix configure option is broken, but it is not necessary
to use it as long as wx-config is in the path).
I noticed the following problems running Mahogany:
* The IMAP support seems to be mildly incompatible with our servers,
such that every time a message is read it reports a server
complaint of a missing argument to fetch, although the message
contents appeared to be fetched without difficulty. This problem
would most likely be easy to resolve.
* The interface for sending a message pops up two dialog boxes if
you don't have a .signature file. This should be easy to quell,
but does suggest a worrisome lack of consideration in the design.
* The user interface did not seem very intuitive or efficient to me.
For instance, selecting a folder does not open it (you have
double-click it, press return, or select "open" from its context
menu), and there did not appear to be a key binding for deleting a
mail message.
* The user interface is kind of messy, and has a number of features
inappropriate for an end-user at a big site like ours. It makes
excessive use of dialog boxes (many of which can be disabled by
clicking a checkbox), displays a separate window with a text log
of various events and error messages (which is useful as an option
for debugging, but distracting as a default), and has a file of
tips of the day.
* I did not get native HTML message display in my build (I'm not
sure how hard it would be to configure it), and this version of
Mahogany has no HTML editing support for messages being sent.
* While trying to create a folder, it decided to stat the entries
under /afs while I was doing something unrelated.
I suspect bug-fixing work on Mahogany would be relatively limited, but
I anticipate we would need to make the following local modifications:
* We would need to add Hesiod support.
* We would need it to preconfigure itself with appropriate settings,
to prevent it from popping up a configuration wizard when first
run.
* As with most other mail clients, Mahogany insists on including its
own inbox folder, located in the user's home directory, in the
folders tree. We would need to remove that assumption.
* We would need to clean up the interface significantly. This change
might prove difficult to maintain because it would require changes
to many parts of the code, and because user interface changes
often don't merge terribly well.
Here are my estimates of the initial work required, assuming
relatively solid commitment by one developer:
Task Range Likely
Debugging 1-4 weeks 1 week
Preconfiguration 1-3 weeks 1 week
Suppressing local mail folders 0.5-2 weeks 0.5 weeks
User interface cleanup 1-4 weeks 3 weeks
Total 3.5-13 weeks 5.5 weeks
Here's my grade sheet:
Factor Grade Comments
Ease of integration B
Ease of debugging B
Features C Lacks HTML editing, non-intuitive interface
Maintenance C Need to maintain local changes to UI
Overall C
