Porting an e-Mail app to Haiku - suggested approaches?

[nmatavka]

A few years ago, I came into the possession of the source code for both versions of QUALCOMM Eudora (for Windows and OS X). I say both versions because the two apps have nothing in common at all save for the UI, and even this is far from an exact copy. It may be worth mentioning that the OS X app is the original; Eudora for Windows is a rewrite (not a port as I define it - which comes from an upstream codebase and has a few things patched).

I’ve had to change the names for legal reasons, such that Eudora/Win is now known as HERMES Aurora and the Mac product is now HERMES Eos. Of course, this matters little for development, but it does bear mentioning.

Anyway, Aurora has been running on Windows (it took the entire COVID pandemic for us to reach that point) for over a year now. Aurora features Wine compatibility as an intentional design strategy, so naturally it will run on Haiku as well, and that’s one of the options a potential “Eudora for Haiku” could represent. It’s written in C++ with reliance on Perforce Stingray Studio, an MFC-like GUI framework for Windows.

Thanks to a Eureka moment for yours truly, we’re at the point where Mac development, at least for Intel Macs running Mojave or older, will be a cinch. (To explain: all the resource forks were thought to be lost, until I figured out a strategy for digging them up.) Eos is written in C with reliance on Carbon; its settings and many of its assets (toolbars for example) are stored in the resource fork.

Haiku uses resource forks in a fairly Mac OS 9-like way (although software is distributed on disk images, in a NeXT-like way) in that it has something like a database file system. It also uses C++, like Windows, and is pervasively multithreaded, unlike Windows.

So I’ve come up with several possibilities for a Haiku package. 1) As mentioned, HERMES Aurora, packaged together with Wine as its dependency. 2) A rewrite of Aurora for Haiku. 3) A rewrite of Eos for Haiku. (There is no possibility of porting either of the apps to Haiku, as neither use portable API’s - unless BeAPI is very similar to Carbon, which I doubt.) What’s people’s opinions on the option to be preferred here?

[extrowerk]

What about working on the default mail instead of porting 3rdparty alien stuff?

[nmatavka]

That’s not an option. I like the Eudora workflow and want to import this workflow into Haiku. My ideal choice would be to port Eudora for Windows (Aurora) to Haiku, but that’s not possible since it’s not a Qt app, or even GTK.

I’m not the only one doing a Haiku mail client. There’s also Trojitá in HaikuPorts. Don’t be a software Bolshevik.

[extrowerk]

I did the Trojita port so stop callinge names.

What the legal status of the Eudora sources?

[nmatavka]

@extrowerk

What the legal status of the Eudora sources?

Original Eudora sources belong to the Computer History Museum and are MIT-licenced. These sources don’t compile on anything, not Windows, not Mac. (MIT licence is why I had to change the name.)

Our (HERMES’) updated sources are ours (copyright 2023, Team Hermes, (c) 2018, CHM). Windows one will be MIT-licence EXCEPT FOR one file containing Perforce Stingray, which belong to Perforce and is proprietary. Eos (Mac Eudora successor) will be GPL on release in February, mostly because it’s deprecated for its original use (i.e. OS X no longer implements Carbon).

But remember, we’re not talking about Aurora or Eos, because neither of those will run on Haiku. Well, Aurora will run on Haiku, but only through Wine.

[Null]

Have you discussed rewriting one common code base to be portable across multiple platforms? Because even if you solve the problem with Haiku, you will face the same problem for every future platform you would like to support. So maybe it is best to bite the bullet now to create a better foundation for the future.

I am an old Eudora user and would like to be able to use it again. I am currently using (old versions of) Thunderbird because it functions well enough and has a wide platform support.

[RogFanther]

Some time ago ( well, I think it was 2019 … ) you wrote that you and your friends were rewriting the Stingray library parts in pure MFC, and that your Hermes version wasl already working without the Stingray libraries. Did that not work ?

[nmatavka]

We tried that but as a small team the principle did not justify the expense. The code is… deceptively complex, and there were much more important things, like Unicode support.

[nmatavka]

@Null

Have you discussed rewriting one common code base to be portable across multiple platforms? Because even if you solve the problem with Haiku, you will face the same problem for every future platform you would like to support. So maybe it is best to bite the bullet now to create a better foundation for the future.

I wouldn’t say we’ve discussed it, because consensus was formed very early on: the concession to UNIX people is Aurora on Wine, not any kind of rewrite for GTK or Qt, because UNIXers are a technical bunch and explaining to them that Aurora does what they want in such-and-such a way is taken as axiomatic.

Haiku is a whole other kettle of fish (even though it’s technically a UNIX in the same way OS X is). Haiku people are not expected to be comp-sci undergrads or the Neil Goldmans of this world. So… UNIX, Windows, OS X, and Haiku represent ~99% of desktop operating systems. I don’t think there’s another architecture waiting in the wings that wants an e-Mail client.

@Null

I am an old Eudora user and would like to be able to use it again. I am currently using (old versions of) Thunderbird because it functions well enough and has a wide platform support.

Have you tried HERMES Aurora? You can get a copy right now, by contributing at least $1 to the project. It already exists, has existed for a year and a half, so you’re not risking anything.

[Null]

@nmatavka

(even though it’s technically a UNIX in the same way OS X is)

I do not consider Haiku to be UNIX in any way, shape or form. I consider Haiku to be the opposite of UNIX.

UNIX are made up of individual, stand alone parts. It is fragmented. It is not user friendly. User friendliness is an after thought and slapped on top of the fragmented mess, like putting lipstick on a pig.

Haiku is a unified, coherent and user friendly.

@nmatavka

Have you tried HERMES Aurora? You can get a copy right now, by contributing at least $1 to the project. It already exists, has existed for a year and a half, so you’re not risking anything.

No I have not. I did not know it existed until today. I’d love to try it out, but not if it means having to support evil sites such as Indiegogo.

[donn]

Is the question here somewhat like “which API is going to be less trouble to translate to the Haiku API”, as the key factor in deciding between Aurora and Eos?

I’ve done very little with either, but my guess is going to be Windows. You could probably do better than my guess with a cursory examination of the basic API.

[nmatavka]

@Null

I do not consider Haiku to be UNIX in any way, shape or form. I consider Haiku to be the opposite of UNIX.

UNIX means, technically, “implements POSIX/the Single UNIX Specification”. Haiku indisputably does conform to the definition of UNIX (not in a legal sense, but in all senses short of legal, yes).

@Null

UNIX are made up of individual, stand alone parts. It is fragmented. It is not user friendly. User friendliness is an after thought and slapped on top of the fragmented mess, like putting lipstick on a pig.

Haiku is a unified, coherent and user friendly.

What you have written here applies to Linux and to the GNU utilities grafted on top. Linux, because Linus intentionally set out to write a “quick and dirty” kernel that’s “nothing like Research UNIX or the Hurd”, and GNU, because those people were left-wing socialists who let their fragmented politics translate into engineering, and that is A Very Bad Idea. Put those two together, and you have what Army people call a goatfuck, a clusterfuck, or a TARFUN moment (“Things Are REALLY Fucked Up Now”).

Haiku is not Linux or even close to Linux. BSD has coherence and (to the extent that OS X is a BSD) user-friendliness as well. Haiku is closer to BSD (I mean, it descends from Gassée’s idea of how Apple “Taligent”/“Pink” should get back on track, so this is kind of obvious), and it’s even closer to Fuchsia.

@Null

@nmatavka

Have you tried HERMES Aurora? You can get a copy right now, by contributing at least $1 to the project. It already exists, has existed for a year and a half, so you’re not risking anything.

No I have not. I did not know it existed until today. I’d love to try it out, but not if it means having to support evil sites such as Indiegogo.

I’ll PM you. The reason I’m promoting Indiegogo is because that’s really the only place that explains what we’re all about - but I’ll tell you where to download the software, where to turn to for support, and if you want to send a contribution to support us, I’ll take PayPal.

@donn

Is the question here somewhat like “which API is going to be less trouble to translate to the Haiku API”, as the key factor in deciding between Aurora and Eos?

I’ve done very little with either, but my guess is going to be Windows. You could probably do better than my guess with a cursory examination of the basic API.

Somewhat, but there’s also the option of a hpkg that installs Wine as a dependency, invokes Winetricks, and runs Aurora under Wine. So it’s a three-way question rather than two-way.

I mean, Haiku’s basic API is, on cursory examination, dissimilar to either; it uses message-passing and pervasive multithreading in such a way that, at least from an engineering point of view, familiarity with the concepts behind Elixir or Haskell might not go amiss. Architecturally, though, it seems to take a number of concepts from Carbon - in a C++ like way.

[bitigchi]

This is a great service to the computing community, I adored Eudora back in the day.

Seeing the screenshots for the old Macintosh version, I can’t help but think, that the separate utility windows based interface is still superior compared to single-window interfaces.

I would love to see a native Haiku GUI! I think I’ll try the macOS version when it comes out! I like Apple Mail, but the way it handles plain text could be improved. Neo/Mutt is sometimes too boring. The other clients all try to reinvent the wheel.

Good luck with everything!

[win8linux]

Wine breaks readily at the moment and still doesn’t have multiarch support (due to Haiku not having this yet). Unless your team has the bandwidth and will to also contribute to Wine for Haiku, rewriting either Aurora or Eos.

[PulkoMandy]

@extrowerk

What about working on the default mail instead of porting 3rdparty alien stuff?

That’s a job for Haiku contributorse not for Eudora/Hermes/Aurora developers, right?

@nmatavka

What’s people’s opinions on the option to be preferred here?

It’s your project, you do whatever you want. Of course, it would be better (if you ask me) if this ends up in a native client (not using Wine, and using our Be API widgets). I don’t think it really matters which codebase it is based on, as the whole GUI would end up being rewritten anyways?

[donn]

@nmatavka

I mean, Haiku’s basic API is, on cursory examination, dissimilar to either; it uses message-passing and pervasive multithreading in such a way that, at least from an engineering point of view, familiarity with the concepts behind Elixir or Haskell might not go amiss. Architecturally, though, it seems to take a number of concepts from Carbon - in a C++ like way.

Coincidentally, I have used Haskell for a Haiku API email client. I make sort of a hobby of foreign wrappers for the C++ API, with an IMAP email client as a test application.

At the moment it’s an Ocaml application. Ocaml is another functional programming language, but without Haskell’s pure/evaluated split. I don’t think there was anything lost - same basic principles apply.

Maybe the key point is that you “dispatch” via messages from one application thread to another, from user input events to the application threads, etc. Building on that helps preserve sanity, rather than a lot of global shared data that would have to be access interlocked.

[lelldorin]

Anyone can port what they see fit to Haiku, but I would be happy if someone would update Beam so that we could use this comprehensive, native and good program for all mail providers (I think there are currently problems with gmail accounts).

But it could also be that my level of knowledge is out of date.

[lelldorin]

@nmatavka

and it’s even closer to Fuchsia.

I would say the other way around, because Haiku was for Fuchsia iirc.

[cocobean]

@nmatavka

So I’ve come up with several possibilities for a Haiku package. 1) As mentioned, HERMES Aurora, packaged together with Wine as its dependency. 2) A rewrite of Aurora for Haiku. 3) A rewrite of Eos for Haiku. (There is no possibility of porting either of the apps to Haiku, as neither use portable API’s - unless BeAPI is very similar to Carbon, which I doubt.) What’s people’s opinions on the option to be preferred here?

Look at Mailspring v1.13.2:

• Foundry376/Mailspring: A beautiful, fast and fully open source mail client for Mac, Windows and Linux. (github.com)

You mainly want low dependency overhead, ease of maintainence, and ease of porting, …

Wine - no. Overhead.

[SamuraiCrow]

Re:overhead

Viewing an HTML email in this day and age practically requires WebKit or some such library. The ship has sailed for email having low overhead. Much moreso for the web (as I type this on a Javascript-based web app).