I feel like I need to re-iterate a few things on this project: HERMES Mail is defined by what I believe is a rather narrow scope: an eMail client based upon as much code from QUALCOMM Eudora for Windows as viable, and compatible as possible therewith. I have had suggestions floated about using a relational database as a mailstore (this would thoroughly break compatibility), and the HERMES Mail demonstrator thus far built is a non-functional "sandbox".
Please tell me that we're at least on the right track. I'm dying of nerves here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am quite happy for Hermes to be developed along your original line.
After all I don't think users should be requesting all sorts of
add-ons or new features. I would be quite satified if the UTF-8 issue
could be fixed and that's about all - but it's not vital.
Regards
Ross Herbert
At 10:26 PM 12/06/2019, you wrote:
Gents:
I feel like I need to re-iterate a few things on this project:
HERMES Mail is defined by what I believe is a rather narrow scope:
an eMail client based upon as much code from QUALCOMM Eudora for
Windows as viable, and compatible as possible therewith. I have had
suggestions floated about using a relational database as a mailstore
(this would thoroughly break compatibility), and the HERMES Mail
demonstrator thus far built is a non-functional "sandbox".
Please tell me that we're at least on the right track. I'm dying of
nerves here.
The problem is that fixing the UTF issue is not nearly as easy as it
appears. Simply put, Stingray-based Eudora (an obsolete package, but
that's neither here nor there) uses Microsoft Internet Explorer's
deprecated MSHTML display engine, which was superseded by EdgeHTML, which
was itself superseded by Chromium. It's not a trivial task to "re-wire"
the source to use Edge, but Chromium is a Google product and therefore uses
radically different procedures and calls...
Then there's the issue of how HERMES Mail interprets the rendered HTML
(which is where all the Eudora bugs actually originate), and that'll
require some thinking as well.
It'll happen, but given the steaming pile of $#!+ on our plate, it'll take
some work, is what I'm saying. And of course, me being manager, it's
practically guaranteed that errors in judgement will be made along the way,
and there's even odds of me recognising those errors when they appear (as
opposed to, say, a year down the line).
I am quite happy for Hermes to be developed along your original line.
After all I don't think users should be requesting all sorts of
add-ons or new features. I would be quite satified if the UTF-8 issue
could be fixed and that's about all - but it's not vital.
My two cents, I agree completely with your position but would add one critical point, that it be "supported." Meaning that there is a way to log bugs and hopefully have them fixed in 6-12 months time with new releases on about that schedule. By new releases I'm thinking along Walt's position below - evolution not revolution. Simply having a "new" compilation of the Eudura code base targetted at Win7 x64 would be enough to calm my nerves about v7.1.0.9 suddenly not working some day because of Win evolution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the SSL update to Eudora was a major enhancement to keep all of us in the Eudora game. Why deviate from your original "mission"? https://team-hermes.bitbucket.io/hermssl.html What's your current timeframe for beta release of Hermes 8?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to see the same file structure preserved in Hermes. I believe it is rather resilient to crashes which sometimes happen due to various (including hardware failures) reasons. If the e-mail folder structure appears to be corrupt, I typically delete the .toc file and Eudora builds it again from the .mbx file. My assumption is that a crash at a critical moment could be fatal to a SQL database without recovery possibility. The .mbx way has served me well since 1998. I'm eagerly waiting for a working Hermes version to appear.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to see the same file structure preserved in Hermes. I believe
it is rather resilient to crashes which sometimes happen due to various
(including hardware failures) reasons. If the e-mail folder structure
appears to be corrupt, I typically delete the .toc file and Eudora builds
it again from the .mbx file. My assumption is that a crash at a critical
moment could be fatal to a SQL database without recovery possibility. The
.mbx way has served me well since 1998. I'm eagerly waiting for a working
Hermes version to appear.
I also agree. The resilience provided by separate mailbox files is Eudora's
major plus.
By the way, I replaced my SSL ddl with the Hermes one early in the year,
but I still - every week or so - am required by Eudora to add a gmail
certificate to trusted. Does anyone else have this problem?
In the news today: Facebook on Thursday released a JavaScript engine called Hermes under an open source MIT license to improve the performance of React Native apps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gents:
I feel like I need to re-iterate a few things on this project: HERMES Mail is defined by what I believe is a rather narrow scope: an eMail client based upon as much code from QUALCOMM Eudora for Windows as viable, and compatible as possible therewith. I have had suggestions floated about using a relational database as a mailstore (this would thoroughly break compatibility), and the HERMES Mail demonstrator thus far built is a non-functional "sandbox".
Please tell me that we're at least on the right track. I'm dying of nerves here.
Hi Ted,
I am quite happy for Hermes to be developed along your original line.
After all I don't think users should be requesting all sorts of
add-ons or new features. I would be quite satified if the UTF-8 issue
could be fixed and that's about all - but it's not vital.
Regards
Ross Herbert
At 10:26 PM 12/06/2019, you wrote:
The problem is that fixing the UTF issue is not nearly as easy as it
appears. Simply put, Stingray-based Eudora (an obsolete package, but
that's neither here nor there) uses Microsoft Internet Explorer's
deprecated MSHTML display engine, which was superseded by EdgeHTML, which
was itself superseded by Chromium. It's not a trivial task to "re-wire"
the source to use Edge, but Chromium is a Google product and therefore uses
radically different procedures and calls...
Then there's the issue of how HERMES Mail interprets the rendered HTML
(which is where all the Eudora bugs actually originate), and that'll
require some thinking as well.
It'll happen, but given the steaming pile of $#!+ on our plate, it'll take
some work, is what I'm saying. And of course, me being manager, it's
practically guaranteed that errors in judgement will be made along the way,
and there's even odds of me recognising those errors when they appear (as
opposed to, say, a year down the line).
On Thu, 13 Jun 2019 at 05:37, Ross Herbert rherber1@users.sourceforge.net
wrote:
My two cents, I agree completely with your position but would add one critical point, that it be "supported." Meaning that there is a way to log bugs and hopefully have them fixed in 6-12 months time with new releases on about that schedule. By new releases I'm thinking along Walt's position below - evolution not revolution. Simply having a "new" compilation of the Eudura code base targetted at Win7 x64 would be enough to calm my nerves about v7.1.0.9 suddenly not working some day because of Win evolution.
I think the SSL update to Eudora was a major enhancement to keep all of us in the Eudora game. Why deviate from your original "mission"? https://team-hermes.bitbucket.io/hermssl.html What's your current timeframe for beta release of Hermes 8?
I would like to see the same file structure preserved in Hermes. I believe it is rather resilient to crashes which sometimes happen due to various (including hardware failures) reasons. If the e-mail folder structure appears to be corrupt, I typically delete the .toc file and Eudora builds it again from the .mbx file. My assumption is that a crash at a critical moment could be fatal to a SQL database without recovery possibility. The .mbx way has served me well since 1998. I'm eagerly waiting for a working Hermes version to appear.
Yes, of course. This is what I like to refer to as, "non-negotiable". The
flat Unix mailstore will remain.
On Wed, 26 Jun 2019 at 03:02, "Alpo Värri" varrialpo@users.sourceforge.net
wrote:
I agree w/you completely.
Devoted Eudora users are looking for EVOlution not REVOlution.
I also agree. The resilience provided by separate mailbox files is Eudora's
major plus.
By the way, I replaced my SSL ddl with the Hermes one early in the year,
but I still - every week or so - am required by Eudora to add a gmail
certificate to trusted. Does anyone else have this problem?
Robert
On Wed, 26 Jun 2019 at 22:34, Walt Stagner wstagner@users.sourceforge.net
wrote:
--
Robert Czernkowski, PhD, BCom(Hons), FCPA
In the news today: Facebook on Thursday released a JavaScript engine called Hermes under an open source MIT license to improve the performance of React Native apps.