Is there a page which describes the status, progress of this project? I must be blind as I can't find it.
In light of Soren's recent health issue, I wonder if the scope of this project is misguided. I have previously noted that I have only three issues with Eudora 7.1: SSL, encoding/decoding and IMAP. That's it, I have no other issues and I've been a mostly satisfied Eudora user since 2001. SSLhas been resolved by using Stunnel. UTF (and other) decoding and IMAP are still problematic.
I really do not see the need to revamp and redesign Eudora. If we had focused on fixing the problems, we would be closer to accomplishing that goal and having a proper, modern email program.
I realize it's too late to consider changing course here, nor would the "big boys" want to, but that's my opinion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Friday, March 8, 2019 5:33:03 PM EST, Arthur-Boston wrote:
Is there a page which describes the status, progress of this
project? I must be blind as I can't find it.
In light of Soren's recent health issue, I wonder if the scope
of this project is misguided. I have previously noted that I
have only three issues with Eudora 7.1: SSL, encoding/decoding
and IMAP. That's it, I have no other issues and I've been a
mostly satisfied Eudora user since 2001. SSLhas been resolved by
using Stunnel. UTF (and other) decoding and IMAP are still
problematic.
SSL has also been resolved with Hermes SSL Extensions for Eudora. That's
our stopgap measure.
As for encoding/decoding and IMAP, we can't fix those issues unless we can
bundle a new HTML rendering engine (Trident can't keep up with Unicode) and
a new IMAP DLL (which we already have). We can't compile the existing
Eudora interface code, because we don't have the rights to the toolkit upon
which it depends, and the interface we have right now is rudimentary at
best.
I really do not see the need to revamp and redesign Eudora. If
we had focused on fixing the problems, we would be closer to
accomplishing that goal and having a proper, modern email
program.
Except we can't, due to the toolkit issue mentioned time and time again.
If QUALCOMM had used an industry-standard graphics toolkit, we would've had
HERMES Mail done and dusted by this time. Problem is, they didn't.
Trying to explain this to a majority non-technical audience is like talking
to a brick wall. I apologise for any lingering frustration, but the
closest analogy I can come up with is having all the parts to a car, plus
the technical drawings... but not the dashboard. We can't sell the car
without the dashboard, we can't use the original dashboard because it's out
of production and using the new generation of that dashboard would be
illegal, so the only thing we can do is try to make our own dashboard and
mirror the old one as closely as possible.
I realize it's too late to consider changing course here, nor
would the "big boys" want to, but that's my opinion.
Status of project, scope?
We're playing catch-up, essentially. The interface is coming along pretty
well, but of course there have been delays.
The scope of the project, as has been said both explicitly and implicitly,
is to clone Eudora's existing interface using an industry-standard toolkit,
and to use all parts of Eudora that can still be used (the back end and all
the engines).
I would like to expand a little on the IMAP question. I have spent some considerable time looking at the IMAP code because IMAP is one area of Eudora's operation that I would very much like to enhance for my own purposes. And one might expect that this should be easy, as it was with SSL, given that IMAP appears to be implemented in a DLL. However it is not easy for the reason Mr. Matavka mentions: because the IMAP code is ensnared with MFC and other UI code. In fact, only about half of the IMAP code is in the IMAP DLL while the other half is in the monolithic Eudora.exe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there a page which describes the status, progress of this project? I must be blind as I can't find it.
In light of Soren's recent health issue, I wonder if the scope of this project is misguided. I have previously noted that I have only three issues with Eudora 7.1: SSL, encoding/decoding and IMAP. That's it, I have no other issues and I've been a mostly satisfied Eudora user since 2001. SSLhas been resolved by using Stunnel. UTF (and other) decoding and IMAP are still problematic.
I really do not see the need to revamp and redesign Eudora. If we had focused on fixing the problems, we would be closer to accomplishing that goal and having a proper, modern email program.
I realize it's too late to consider changing course here, nor would the "big boys" want to, but that's my opinion.
On Friday, March 8, 2019 5:33:03 PM EST, Arthur-Boston wrote:
SSL has also been resolved with Hermes SSL Extensions for Eudora. That's
our stopgap measure.
As for encoding/decoding and IMAP, we can't fix those issues unless we can
bundle a new HTML rendering engine (Trident can't keep up with Unicode) and
a new IMAP DLL (which we already have). We can't compile the existing
Eudora interface code, because we don't have the rights to the toolkit upon
which it depends, and the interface we have right now is rudimentary at
best.
Except we can't, due to the toolkit issue mentioned time and time again.
If QUALCOMM had used an industry-standard graphics toolkit, we would've had
HERMES Mail done and dusted by this time. Problem is, they didn't.
Trying to explain this to a majority non-technical audience is like talking
to a brick wall. I apologise for any lingering frustration, but the
closest analogy I can come up with is having all the parts to a car, plus
the technical drawings... but not the dashboard. We can't sell the car
without the dashboard, we can't use the original dashboard because it's out
of production and using the new generation of that dashboard would be
illegal, so the only thing we can do is try to make our own dashboard and
mirror the old one as closely as possible.
We're playing catch-up, essentially. The interface is coming along pretty
well, but of course there have been delays.
The scope of the project, as has been said both explicitly and implicitly,
is to clone Eudora's existing interface using an industry-standard toolkit,
and to use all parts of Eudora that can still be used (the back end and all
the engines).
I appreciate the detailed reply. I don't believe I'm a brick wall, last time I checked, so your reply is not moot!
I wasn't aware of the toolkit issue but it is understandable.
Wishing all of you continued progress and success.
I would like to expand a little on the IMAP question. I have spent some considerable time looking at the IMAP code because IMAP is one area of Eudora's operation that I would very much like to enhance for my own purposes. And one might expect that this should be easy, as it was with SSL, given that IMAP appears to be implemented in a DLL. However it is not easy for the reason Mr. Matavka mentions: because the IMAP code is ensnared with MFC and other UI code. In fact, only about half of the IMAP code is in the IMAP DLL while the other half is in the monolithic Eudora.exe.