Project Plan, Part II

Goal - The Big Picture

Version 7.9º of HERMES Mail will at least compile and run on Microsoft Windows without unfree dependencies. It will be able to negotiate a SSL/TLS handshake, send mail through SMTP, receive mail through POP3 and IMAP, and display UTF-8 mail, ideally using the Chromium Embedded Framework (hereafter, the "Framework"). Ideally, it will also check spelling using Nuspell.

Version 8α must be able to display HTML mail using the Framework, check spelling and filter spam using Bogofilter.

º - To maintain continuity with Eudora, the first public release (which may lack features from goal) will be numbered 7.9, then 8α, 8β, 8γ (release version), 8.1α and so on.

Dependencies

The overarching goal for version 7.9 is the removal of unfree and outdated dependencies and their replacement with free, modern equivalents. They are primarily:

• Stingray Objective Toolkit - user interface code without which HERMES Mail will not compile. To be replaced with MFC? WxWidgets? GTK?
• Wintertree Sentry - spelling checker. To be replaced with Nuspell.
• Trident (MSHTML) - display engine for HTML mail. Gecko has been floated as its replacement, but the work needed would be inordinate. Therefore, to be replaced with the Chromium Framework, supra.
• Spam filter - the code for this has apparently been removed by Qualcomm. To be replaced with Bogofilter.
• InstallShield - costs money. To be replaced with NSIS.

Timing

It is anticipated that the inaugural release of HERMES Mail will be in the first quarter of 2019. A January release appears to be possible given the existence of the Framework; having to adapt Gecko to the task would seriously complicate matters.

Further releases ought to be quarterly. That gives us enough room to fix bugs, respond to user feedback, and most importantly stay modern. Whether this takes the form of a fixed three-month schedule or "when it's ready" is a matter for debate.

In regards to the individual dependencies, the Chromium Framework is a clean build for precisely this sort of application, and it should therefore take (conservatively) less than a month to implement. Nuspell and Bogofilter should take a month or two. Stingray is the big one and depends heavily on skills and manpower: we need people knowledgeable in MFC to replace it with a viable alternative. I would give it the full six months—it is a big part of the reason HERMES Mail won't compile as-is. InstallShield is a wild card; it can be replaced quickly, but only if we know what exactly is included in the distribution. It ought to be done only after we get the project compiled.

Manpower

We currently have three coders. Jeff Prickett is on hiatus, although he has hinted that his hiatus may be short term only. Pete Maclean is working primarily on QCSSL; he has admitted to having little knowledge of MFC, and his assignment to a task that includes the latter would therefore be a gross waste of resources. Søren Thygesen does have MFC proficiency and use of his skills in the appropriate area(s) is therefore vital.

Further recruitment of manpower will be through advertising on the Help Wanted boards on SourceForge, as well as on the CPlusPlus, OpenSource, and FreeSoftware subreddits on Reddit.

[Walt Stagner]

Will Hermes be able to coexist with Eudora 7.1, or will it be a choice of EITHER running Hermes OR Eudora? I would think this would be helpful for testing purposes.

[Ted Matavka]

It should be possible to run them concurrently.

[Pete Maclean]

Concurrently using a single set of mail folders or only using separate sets of mail folders?

[Walt Stagner]

Thanks for the update, Ted.
I'm sure that a duplicate set of email folders will be required UNLESS the Hermes install will allow you to specify the data files location SEPARATELY such as in aTools/Options setting. Eudora only allows you to specify this during the intial install. In my case the program and data files are in c:\eudor301. So, if I want a separate Hermes install, I'd specify c:\hermes during the install as where the program & files go. I think allowing allowing a tools/options setting for data files would be an enhancement, since this capability doesn't currently exist in Eudora.

[Walt Stagner]

Upon pondering this further it especially makes sense, during testing, to keep Eudora & Hermes data files separate.....at least until we're all confident that Hermes will maintain our mail data files' integrity. Versions of Eudora prior to 7.1 had a nasty habit of sometimes corrupting data files during mailbox compaction. Then you'd either lose some email or messages would have ? next to them with no way of fixing this via a menu option.

I also looked at the Eudora 7. 1 mailbox import tool and the only import options are Outlook, Outlook Express, and Netscape. My how times have changed. Obviously it would be nice to get a few more options here....especially for Thunderbird. I'm sure many people abandoned Eudora for Thunderbird at some point (I never could pull the trigger) and if Hermes had a Thunderbird import filter, I'm sure Hermes would get some of those li'l birdies back. :-)