The Project Plan

There have been whisperings that this project is insufficiently planned, with no roadmap, goal, or division of labour to speak of. This is unfounded, as the project plan was the first thing done, before a single line of code was added; that said, the plan circulates privately via eMail as a file in Spacemacs .ORG format, rather than being hosted on a public site, largely because it is in a state of perpetual flux. The rapid changes have recently died down, and I have therefore decided that it's beyond high time that the plan be publicised. Without further ado, here it is, along with my comments:

Root Certificates (done; ongoing)

Eudora 7.1 has trouble accepting and validating Secure Sockets Layer certificates. This is a two-part problem. First of all, its list of trusted certificate issuers is out of date. To elucidate why that might be a problem, imagine the various paper, plastic, cardboard, and even organic "symbols" that you're prepared to accept as identification. You may be inclined to trust, for example, a driving licence issued by the DVLA in England, if the photo matches the man who's holding it. You might also trust the real grip of a Master Mason, combined with a dues card issued by the Prince Hall Grand Lodge of Alabama. You might trust a student identification card from Harvard University. You will most probably NOT be inclined to trust someone who waves a playing card that he signed and on which he drew a picture of himself.
The notional list of "authorities" you trust is your root certificate store - in the case above, the English DVLA, the Grand Lodge in Alabama, and Harvard University. Eudora was last refreshed in 2005, so it trusts only institutions that existed as of that time. I fixed it, but we've run into a second issue...

QCSSL + OpenSSL (done; ongoing)

It doesn't matter whether a certificate (equivalent, if you've read the above, to the sort of ID you wear about your person) is on your mental "trusted list"/root cert store. You will not trust it if you can't READ it. Unfortunately, that is the problem we're facing; the "syntax" of the SSL "language" has changed since 2005, mostly because of Heartbleed, and clients written before that time can't understand certificates written/issued since then.

Stingray (TO DO)

As orig. written, Eudora used "Objective Toolkit", a $3700 UI toolkit published at the time by Stingray Software, then Quovadx, and now RogueWave. This made a lot of sense in 1995 (because the Windows-native MFC toolkit was just starting out), it made a little bit of sense in 2005 (because MFC still lacked a few features, notably docking sidebars), but it sure doesn't make any sense now. It doesn't make sense economically (Objective costs $3700, MFC costs nothing), it doesn't make sense technically (MFC supports "Wazoo" bars now, apparently), and it doesn't make sense legally (we can not distribute Objective as part of the source).

We therefore must convert all Objective references to native references. Every platform uses a different native toolkit, though (Objective ran on Windows only). For Windows, this is MFC; for Linux, it's the GNU Toolkit (GTK); for Mac, it's Cocoa. Windows is, at least for now, the priority, though Hermes can and should be made cross-platform.

HTML Rendering (TO DO)

Eudora 7.1 uses two renderers. One is DataPak Paige. This had been slated to be removed by Prickett but after some discussion, it has been granted a reprieve. Paige is a very old renderer (older than HTML itself, as a matter of fact) but it is light, it is ours (was bought out by Qualcomm and open-sourced along with Eudora), and perhaps most importantly, it is SECURE. This makes it nothing short of perfect for a) those users whose computers run at the speed of smell and b) those users who think tinfoil millinery makes a great fashion statement.

The second renderer is MSHTML, also known as Trident, also known as T-R-O-U-B-L-E. Trident is the HTML engine included with Microsoft Internet Explorer, which should tell you all you need to know: not only was MSIE a poor excuse for an Internet browser from day one, but it's actually been shitcanned by its own development team in favour of MS Edge. How bad does a program need to get before you say "OK, team, we're throwing 10+ years of effort out and starting from the top"? Exactly. It only gets worse from there, because it is possible to write an eMail that, when previewed (NOT opened) in Trident, will open its attachment automatically---a behaviour that would give John McAfee conniption fits.

The solution we've agreed to is that we'll remove Trident and instead include Gecko (the HTML renderer used by Seamonkey, Firefox, and Thunderbird). It is much more secure, faster, and better in every way than Trident. It'll be a lot of work, but I confide that we can get a clean build running. If we can't get Gecko, maybe Webkit is an alternative, but I am a Gecko partisan and Prickett is agreed with me.

UPDATE: I have instead decided that we will go with Blink (the HTML renderer used by Google Chrome and Chromium). There is no "framework" version of Gecko, suited to be included in third-party apps for the display of HTML content; there is, however, the Chromium Embedded Framework, explicitly written for just that purpose. I have therefore decided that we will be using it.

Unicode a/k/a UTF-8 (to do)

While I consider English and Latin the two truly international languages, not everybody uses them for all their communication. It is therefore a high priority to make Hermes compatible with UTF-8, the global standard that assigns codes to all those European accents (and other things).

I am not sure whether this should be done before or after Trident (MSHTML) is replaced. If Unicode support is linked to Trident, it would be best to wait; otherwise, someone should get on it PDQ, as it has been a feature requested to no end, for very good reason.

Daniel Kuhn suggests this algorism: "To check if a message is UTF-8 encoded, ... look at the message header "CONTENT-TYPE:" and check if it contains the strings "CHARSET" and "UTF-8". If those strings are not found, the message stays untouched in the automated mode. ... Only message parts of the type "text/plain" and optionally "text/html" are [to be] processed, so binaries stay untouched."

Spellcheck (to do)

HermesSpell library

In Prickett's words: Let's "factor out how the current code calls the spellchecker and then create a class that works the way the old Eudora spellcheck did. If we do this successfully, we will not have to do a lot of changes to the legacy Eudora codebase for spellcheck to work." He goes on to say: "I think the best solution is to add a HermesSpell interface between the new open source library and the way the old legacy code interfaced with the old spellchecker libraries. If spellcheck is enabled on the first build, I strongly suggest that it be included with the main download. If it turns out we need to have things downloaded for spellcheck to work then I vote for spell check to be disabled or the build release to be delayed."

"There is, also, the concept of risk. Defining and working the way the current version works might reduce risk in that it minimally changes the old codebase and might give us a way to test the codebase from unit test frameworks. It just maybe a good idea to define all the tasks that the current spellchecker does and encapsulate that in an interface so if we later decide to switch from nuspell we only need to implement the one file, a c++ source file that implements that class, instead of tracking down every instance of nuspell in the Eudora module. If this is done correctly, it should be trivial to support multiple spellchecker implementations in the same version of Hermes so the user could configure the spellchecker. If this is done right it should help in the long run."

Replace Wintertree with (preferably) NuSpell

The two possible replacements for Sentry are nuspell (experimental) or hunspell (stable). In any case, replacing Sentry is MANDATORY - it's closed source (though bought out, so it doesn't matter terribly) and very outdated. We don't know how the dic files are built, either, which SERIOUSLY retards my work.

My justification: "Wintertree Sentry, the spell checker included with Eudora 7, is a library with moving parts and dependencies. During the time Eudora was frozen in carbonite, so to speak, it's highly likely that aforementioned dependencies were updated or otherwise modified. The obvious risk that such changes can bring is that building Sentry afresh would break something important in Hermes. I propose replacing Sentry with nuspell. It's an actively-maintained successor, written in pure C++, to the famed hunspell engine. Among the myriad software packages that include either nuspell or hunspell, Emacs, LibreOffice, Firefox, Chrome, Thunderbird, The Bat, InDesign, Illustrator, FrameMaker, Eclipse, and Mac OS X are only a few."

Prickett adds: "There is also the tradition of Open Source projects using other open source projects and not relying on closed source software. At least, the core versions, there maybe hooks in or addins to open source software that use closed libraries, but this should be avoided for core functionality."

Compile Hermes (HIGH PRIORITY!)

Self-explanatory. This is our core deliverable! We need a product that users can download from SourceForge, install, and have a ready-made eMail client that sends and checks messages, including on secure (SSL) servers. Everything else is window dressing!

Installer (to do)

Eudora 7.1 used InstallShield for an installer. As there is a tradition of FOSS projects using other FOSS projects whenever possible, and especially as InstallShield costs $2000 and we want to keep things legal as far as possible, this decision will have to be re-visited. The most likely replacement is the Nullsoft Installation System (NSIS). In fact, as far as I know, it's the only possible/realistic replacement.

Migrating from Shield to NSIS will probably be very much like a BTK amputation: a colossal pain in the patootie but something we will have to do, and worth it in the end. Thankfully, the Shield installer is 100% in script rather than being an MSI, which should simplify things (NSIS is script based). The script lives in EudoraProject.ism.

Caveat: This can only be done once Hermes is compiled. Much Eudora 7.1 code is devoted to user tracking and revenue collection (profile, registration, Paid/Sponsored/Lite Mode), and the compiled version of this "feature" is very probably split across multiple assets (registry, DLL's, etc) for tightness of integration (i.e. to make it harder to remove). Since this "feature" is going away, I don't want to include its assets in the install script, only for it to complain that it can't find (intentionally removed) file XXX.

MoodWatch (Werner/Prickett)

Prickett advocates removing this as he feels it's outdated, especially if we can't edit its dictionary. We can (see architecture notes). Per Werner, we can still make use of it.

Paige and Protocols (Prickett)

HERMES Paige

Prickett wants to bring Paige up to snuff (i.e. XHTML). He makes the very valid point that "it can become a Hermes subproject that would produce something useful---another lightweight open source HTML control---[for] which there really are not a lot of options, [whether] closed or open source."

Protocol Engines (POP, SMTP, IMAP)

This isn't a strict TODO, but P. thinks we might do the same for the protocol engines (POP, IMAP, SMTP). "If we are able to salvage that code moving forward, we can release those dll's and interfaces as subprojects. There are a few more mail libraries out there, but there are not many more mail libraries than HTML controls." He has Werner's blessing for this endeavour.