I looked a little into the mail apps for Haiku. As the native mail program is utilizing the filesystem’s tags I wanted to ask some questions about the future of the mail program(s):
- Is there any current work for improving Mail?
- Does Mail support plugins like the Tracker?
- Does Mail have support/integration for People (like using People for storing/receiving crypto keys)?
- Is there some discussion about future features of Mail (encryption/signing)?
- Mail or ?
A good program is Beam, but i does not know if it is running perfect at the moment, long time no work on it.
Thanks. I will look into it.
I assume that Mail would still be the preferred solution if someone would work on it?
Mail got some pretty significant bugfixing since the beta, otherwise there isn’t a ton of activity, no. We are more focused on general system stability; if there was more developer time to go around, we’d probably invest some of it into Mail indeed…
I have found email apps. It took a while but I got one to work.
Mutt: Installed twice but cannot find it.
Beam: Have not been able to connect with anyplace and have tried numerous configurations.
Mail: No luck getting it to work.
Trojita: This one works for me. Did not have to change any settings and it works like a charm - IMAP.
I will work with Beam later on - I like the looks of it.
Mutt is TUI program, you can start it from terminal.
Sounds interesting. Is it possible to create a gui for it?
But i would like to see Beam running correct again on Haiku.
No. It’s a TUI program. So, writing a GUI would be like:
- Remove all the sourcecode
- Write a GUI based mail client.
Mutt looks like this. Afaik PulkoMandy uses it, but not from Haiku.
I use Terminal email software all the time. Windowing graphics are nice, but an email program that does what you need is the main thing, and if it runs a TTY interface you can take it just about anywhere. The software I use actually started out as a window graphics application on BeOS, but some time after y2K NetPositive was no longer able to keep up with web interfaces, so I have been principally using MacOS X since then. I wasn’t going to invest the time in learning to deal with Cocoa etc., so I went TTY with it on MacOS. Little difference.
Right, however I also use the Rainloop webmail on my own server quite a lot, and not that much of mutt these days. I would probably be happier with an IMAP filesystem
There is https://github.com/nshiell/fuse-imap but ideally you’d want something that uses attributes.
https://www.sr71.net/projects/gmailfs/ is purportedly for gmail only but uses imap and does support xattr.
Also, they are both written in python, which isn’t ideal for haiku.
EDIT: Also, they both seem quite dead.
@PulkoMandy how would you envisage attachments working? And what would be used for editing attributes (To, Subject, CC, …)
Ideally, it would just show each mail as a file in our standard mail file format, so we could open them with the existing Mail app. But there would be no need for the mail_daemon making a download of the inbox (I don’t need a copy of the 20000 emails I have there on my local disk).
So one could move mails in and out of the directory, and manage them as usual.
It isn’t a new idea, I have a vague idea it’s been done. I think the value of it might really be more for people who are living in the command line world, because you have all these tools for working with files. As you get more into an “email application”, the feature match with the filesystem server gets more awkward, and on the other hand it’s easy enough to just implement the features you want and go direct IMAP client.
We already have a Mail application that works with these files. Actually we have two: BeAM and the builtin Mail. None of these are command-line tools and I don’t see why I would be using the command line to manage these files at all. Tracker seems like a perfect tool, make a few queries, move the found files around to new directories in your inbox, etc.
If you’re liking it, there’s nothing wrong with that. I’m just saying, if I’m going to the trouble to write an email client, I’d prefer to do the IMAP protocol there, where it can work when I want it and how I want it to work, and my application would have direct access to observe the proceedings.
But if I didn’t have such an application that I could stand, I’d be mighty glad to have an IMAP filesystem with all those features. And I’d likely put together a sort of substitute for a client using awk etc., but that’s just me - windowing graphics for me usually just means I can have multiple Terminal windows open, and I think I can operate more efficiently in the filesystem that way than I could with a Tracker window, but that’s getting somewhat off the point. However you like to work with files, a filesystem could serve as a sort of last resort IMAP service.
I see it the opposite way: if I’m to write an IMAP protocol implementation, I may as well expose the result as a filesystem so that the existing (and future) e-mail clients can benefit from it.