Is lumail a stepping stone?

14 April 2014 21:50

I'm pondering a rewrite of my console-based mail-client.

While it is "popular" it is not popular.

I suspect "console-based" is the killer.

I like console, and I ssh to a remote server to use it, but having different front-ends would be neat.

In the world of mailpipe, etc, is there room for a graphic console client? Possibly.

The limiting factor would be the lack of POP3/IMAP.

Reworking things such that there is a daemon to which a GUI, or a console client, could connect seems simple. The hard part would obviously be working the IPC and writing the GUI. Any toolkit selected would rule out 40% of the audience.

In other news I'm stalling on replying to emails. Irony.

Tags: lumail, pondering | 8 comments

Comments on this entry

Leandro Penz at 23:40 on 13 April 2014
http://lpenz.org

You can also make it web-based.
Oh wait...

niol at 07:36 on 14 April 2014

Web-based for desktop apps is a good idea. Like the transmission bittorrent client or the git-annex assistant.

Florian at 08:31 on 14 April 2014
http://f5n.org

Web-based for desktop apps is a bad idea. Like GMail. It's one tab out of 10-50 in a browser instance. There's no mental switch, it's still "the browser" - and even unable to use alt-tab to instantly switch to it is a KO criterion for me.

I love native apps (and I just haven't come around to trying lumail) and I've been using Thunderbird nearly since it's inception.

Richard Hartmann at 10:13 on 14 April 2014
http://richardhartmann.de/blog

More than the lack of a GUI, I feel the lack of IMAP/SMTP is the main issue.

With current SSDs, I can not justify carrying around dozens of GiB of mail I almost never need. At least for my use cases, IMAP is an absolute must and unless luamail supports that, I can't even consider switching.

With Alpine dead in the water and my dislike of mutt, I would love to have another MUA to choose from...

Steve Kemp at 10:18 on 14 April 2014
http://www.steve.org.uk/

I have zero interest in a web-view, but I guess it could be contributed (ha).

The IMAP support is something that a lot of people miss, and I can see why. Personally I use offlineimap at times, and that works, but I can see the downside too.

Really my code is focussed on local folder access, and that is so deeply engrained it is hard to change. If I had to write IMAP code I suspect I'd never have reached a workable product/project. But I do wish I'd made it easier to add in.

For the moment I'm making no changes, but I suspect an evolution is inevitable. IMAP has to be added, no matter how distasteful and complicated it becomes.

Andreas Schamanek at 10:53 on 14 April 2014
http://wox.at/as

FUSE imapfs?

Couldn't find any active projects, however, I found one with a cute idea: A scripting language as FUSE wrapper around whatever IMAP library we got (and that works cause implementing IMAP is a PIA, IMHO).

anon at 11:36 on 14 April 2014

Having to run a daemon on your own server also keeps the potential audience very small. I'm keeping an eye on laumail but I can't run it since I neither have my own mailserver to ssh into nor want to download each and every mail with fetchmail/offlineimap while I'm on the road. Why not support IMAP4 (POP3 does not have much relevance today) directly?
There is a distinct lack of a console MUA with support for modern IMAP, e.g. something like Trojita with a TUI.

Nux at 13:35 on 15 April 2014

I've stuck with Cone for the last years, it's doing a good job, though not as flexible as Mutt or Alpine. It might be an option for others, too.

Re Lumail, since I can no longer build it on EL6 (and hence use it) this could be good news.

Is lumail a stepping stone?

Comments on this entry

Recent Posts