Alternatives for Macintosh Eudora
To Rewrite, or not to Rewrite

Introduction
The release of Eudora 7.0 for Windows poses the question of when Eudora 7.0 for Macintosh will be released. It turns out that this is not an easy question to answer. This paper explores some of the ideas that went into planning for the next major release of Eudora for the Macintosh, and examines alternative evolutions for the application.
Background
Before we discuss the problems facing Macintosh Eudora, we should describe some of the design elements of the application, as we will refer to them frequently.
The Mailstore
Eudora’s mailstore was designed when there was very little memory or CPU power available. It used these resources carefully, and was therefore able to perform very well in such limited environments. The basic design is to minimize the amount of processing done on text before it is displayed to the user. Therefore, message text is decoded and transliterated, and attachments and other non-text content are decoded and removed to separate files. The message text itself is stored along with the text of other messages in a file called a mailbox. The same basic mailstore is used in Windows Eudora, though enough details are different that they are not binary-compatible.
Carbon
Eudora uses the Carbon framework for its filesystem access and user interface. This is an older Apple technology, and has been supplanted by Cocoa1 .
The Editor
Of central importance to an email program is the text engine used to display and compose email. Eudora has a custom text editor, that works quite well, but has limited capabilities. It certainly has not kept up with the times regarding HTML standards, especially in the area of table display. Unfortunately, tables are used as a page layout system for nearly all but the simplest HTML nowadays, so this lack is rather keenly felt by users.
The Problems
In the past, it’s been our policy to maintain rough feature parity between the platforms. This has meant releasing versions on both platforms with roughly the same features at roughly the same times. However, this was not done for Eudora 7.0. Below we will explore the problems facing Eudora on the Macintosh. Along the way, we’ll note which of them apply, and to what degree, to Eudora for Windows as well.
Spotlight
Spotlight is Apple’s indexing technology. It is the rough equivalent of the X1 indexing that is being used in Windows Eudora 7. (X1 does not have a Macintosh product.) Unfortunately, Spotlight’s indices have a minimum file-level granularity. Because Eudora stores multiple messages in a single file, Spotlight cannot tell which message a word appears in, only that it appears in a particular mailbox. This makes Spotlight useless for Eudora as it stands today.
Possible solutions for this issue are twofold:

- Redo Eudora’s mailstore to put each message in a single file
- Wait for Spotlight 2.0 (release date unknown) which will be able to index the current mailstore

S/MIME
S/MIME presents an interesting challenge to Eudora. Eudora has long had the capability to do encryption and decryption and handle digital signatures, via a plug-in architecture (EMSAPI). This architecture was necessary due to US government policy regarding encryption technology2 . It is probably no longer necessary, and a more integrated approach is a possibility.
The problem with the current EMSAPI implementation is that it makes dealing with encrypted mail very unpleasant. It is certainly adequate for a functional system, but it is manual, clumsy, and suboptimal, involving attachments and extra user operations. This is the path we took for Eudora 7.0 for Windows. It meets basic requirements, but we don’t expect a high level of user satisfaction if it is used extensively.
Possible solutions to this problem include:

- Redo Eudora’s mailstore to make the encrypted/signed information an integral part of the mailstore, rather than an attachment
- Change the EMSAPI implementation to allow for more automatic operation with the current mailstore
- Tweak the current mailstore to allow non-textual content to be kept intact
- Live with the current suboptimal situation and implement a plug-in similar to that for Windows Eudora 7.0

HTML Handling
One of the biggest user complaints is the lack of sophisticated HTML handling in Eudora. Because we use our own engine and because that engine is severely limited, especially in the area of tables, Eudora’s HTML display can be primitive. This is generally not a problem for most interpersonal email, but it is a problem for much institutional and commercial email, which typically assumes full-blown, up-to-date HTML capabilities.
One obvious solution to this problem would be to use Apple’s HTML viewer/editor, WebKit. However, the problem with WebKit is that it is fundamentally a Cocoa technology. While Apple officially claims it can be used by a Carbon application, they privately admit that it works at best imperfectly in such an environment. While we have been assured by some at Apple that this will be improved, it is difficult to see that as likely, as there is great pressure from Apple for developers to use Cocoa rather than Carbon.
Windows Eudora faces this problem also, but only for email composition; for viewing, it uses Microsoft’s HTML engine.
So, what can we do?

- Redo Eudora in Cocoa rather than Carbon, so that WebKit can be used in its current form
- Upgrade Eudora’s editor to handle tables, and solve the biggest user complaint--but leave a host of smaller ones.
- Wait for Apple to release fixes to its Carbon implementation of WebKit
- Investigate alternate HTML technology, such as Gecko.

Unicode & Non-Roman Languages
Another common complaint from our international users, and anyone who deals globally, is our lack of support for non-Roman languages. While Macintosh Eudora can display and edit anything it receives, much of its internal structure assumes one byte per character, which presents difficulties for such operations as spell-checking and URL recognition. Also, the current mailstore makes no provision for Unicode storage of outgoing mail, so even though mail can be edited, it cannot be saved and sent properly.
Possible solutions to this problem include:

- Redo Eudora using as much of the Cocoa framework as possible, since that is all unicode-friendly. Redo the mailstore to be able to store unicode for outoing mail.
- Tweak outgoing mail storage to support unicode. Fix problems with the internals as they arise.

Windows Eudora shares this problem to a great degree.
Intel Macintoshes
Apple’s transition to Intel hardware raises further difficulties for Eudora. Eudora is currently built with Codewarrior from MetroWerks, a Motorola company. CodeWarrior is not going to support the new machines. While the current version of Eudora will run under the PowerPC emulator (called Rosetta) on the Intel Macintoshes, it will suffer a performance penalty. Just as an added bonus, part of the Eudora development process involves an application which runs under the old Classic emulator, which is not supported at all on Intel Macintoshes.
The two potential solutions to this problem are:

- Rewrite Eudora with Cocoa using XCode, Apple’s development environment
- Move the current codebase to XCode. This will require quite a bit of rework, as there are many minor differences, not least of which is the plug-in architecture, which will have to change, and third-party libraries that are not available for XCode and will have to be replaced

Carbon Limitations
The Carbon framework Eudora uses is, as has been noted, an older Apple technology. While Apple claimes it has parity with Cocoa, in truth there are many capabilities under Cocoa that are either not available at all to Carbon applications, available only after delays for Carbon applications, or only imperfectly available to Carbon applications. We fear this situation will only worsen over time.
Possible solutions include:

- Rewrite Eudora with Cocoa
- Work around as many Carbon limitations as we can, eschew new technologies that are not supported under Carbon, and hope that Carbon support isn’t dropped altogether.

Resource Limitations
The Macintosh market is of course limited compared to the Windows market. However, the complexity of Macintosh software is not so much less than the complexity of Windows software, and it is increasingly difficult to maintain feature parity without spending a disproportionate amount of money doing Macintosh development.
Windows Eudora and Macintosh Eudora are now two entirely different codebases with nearly no commonality. There is therefore little opportunity for work done on one platform to be used on the other; different data structures, languages, etc are used in each. Parallel teams are required for development.
A further complication here is that the data formats from both products are not binary-compatible, so there is no direct way to move data from one platform to another.
Possible solutions to this problem are:

- Rewrite Eudora using cross-platform code as much as possible, so that work done for Windows can benefit Macintosh, and vice-versa
- Compromise on the featureset for Macintosh Eudora
- Continue to spend excessively on Macintosh development so as to maintain a two-platform offering, even if Macintosh revenue does not cover costs

The Way Forward
So, having laid out all of the above, how should we proceed? It seems clear that a rewrite of Eudora for the Macintosh would solve all of the problems above. However, it’s a big task, one we have always been reluctant to take on, necessitating as it would a long hiatus between releases. Our current feeling is that it would take approximately 2 man-years to have an acceptably functional rewritten Eudora of Macintosh. Is there any other way forward?
Let’s recap the issues here, and then see what life looks like if we take some of the non-rewrite paths.

- Spotlight
- S/MIME
- HTML Handling
- Unicode & Non-Roman Languages
- Intel Macintoshes
- Carbon Limitations
- Resource Limitations

Regarding Spotlight, I’m confident that if we wait long enough, Apple will overcome the single-file limitation. It is in fact possible that by the time we would be able to finish the rewrite, the limitation would have been lifted in any case. The S/MIME issue can be worked around in the short term by living with the clumsy EMSAPI, and in the longer term by smaller changes to the application’s calling of the EMSAPI or by internal S/MIME support, without radical changes to the mailstore. Unicode support certainly could be added to the current code without a rewrite, though much of the effort would involve things we would get “for free” from a Cocoa rewrite. There is simply no alternative to moving to XCode to address the Intel Macintoshes. That’s a substantial, but by no means impossible, task.
So much for the simple solutions. That leaves us with three things to solve: the limitations of Carbon, the limited resources for development, and HTML.
The only real long-term solution to the HTML problem is a new text engine, whether it be WebKit or Gecko or who knows what. Fitting any of it into the current Carbon application would not be an easy task. Fixing the table support in Eudora’s current editor would probably ease some people’s concerns for a while, to buy time for such integration. Or HTML support could be left incomplete, and the damage that would do to the market penetration of Eudora on the Macintosh accepted.
The issue of limited resources for Macintosh-only development will remain a significant one as long as the two codebases are separate. If there is organizational will and sufficient Windows revenue, one might choose simply to live with it.
Finally, I think it clear that Carbon will not be immediately eliminated. It was ported to the Intel Macintoshes, which is a good sign. Most importantly, it is used by both Adobe and Microsoft, so there are developers important to Apple who also rely on it. It will likely continue to work for at least two years, perhaps more.
How long would it take to bring Macintosh Eudora up to Windows Eudora 7 features? The biggest uncertainty here is Spotlight. Until the multiple-container Spotlight is released, it’s not possible to do indexed search. Laying that aside, I expect it would take 4-6 man-months of labor to bring Macintosh Eudora to feature parity with Windows Eudora.
In Conclusion
It remains my recommendation that the Cocoa rewrite is the best plan for Macintosh Eudora. It would set up a strong base for the future for both platforms, as the rewritten code will migrate to Windows as well. It would provide for binary compatibility between the products. However, if there is no stomach for the required investment, it would be possible to continue with Eudora on the Macintosh with a less radical philosophy.

1 Cocoa is really just tweaks on top of NeXTStep, which is older than Carbon, but I digress.

2 We really want to editorialize on this point, but we will refrain.

Alternatives for Macintosh Eudora #