Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
lumail 2 - Request for comments/suggestions/feedback #236
I think I've decided that the core of lumail is good, but that the extensibility isn't entirely what I want. The problem is that there are too many special cases, and gaps in the functionality.
My belief is that we should be using objects for most of the code, since we're a mail client there are naturally two objects we care about:
I've written some stub code which works well, as a series of (C++) plugins:
In terms of implementation it is cute to be able to load functions from
This issue is designed really to solicate suggestions or comments on the core idea - which is to first and foremost develop a series of Lua primitives, and corresponding code, which can be tested. If that works well then the GUI layer can be written as a separate job. I suspect that I'm still keen on the modal view, but I could be persuaded to prefer a sidebar of maildirs, and an index of messages.
I could even be persuaded to have an optional GUI layer, but I probably wouldn't write it.
Most of the object methods will fall out nicely, but it's worth making comments here if you have particular tastes. I can certainly imagine and implement the obvious ones myself.
So to start with then the following are obvious functions we need:
I suspect that's enough to replicate the current functionality, but there are some changes. We no longer have "
I'm not sure C++ plugins are required, but if they're there it'd be nice if it's possible to implement a new Maildir type (eg a gzipped mbox) that way by implementing some common interface. So if revisiting things in detail, allowing for non-Maildir mail folders would be great. :-)
I think the very short summary is "Sounds good" and "I mostly like it as it is too."
Thanks for that - looks like our updates just crossed mid-stream.
Don't talk about
The headers I was going to have as a table, but with a helper for just getting a single value. The case isn't a concern because I'd just downcase all header-names - as we do right now. i.e I'd expect a
The use of combined accessor/mutator was done specifically for consistency and to avoid having to write twice as many functions. I still think that is a good choice, but I'm not married to the idea.
I use it daily, and the annoyances don't bug me too much, but I think now I've got this far it is perhaps time to take a step back and just think about what I could do now I know what I'm doing ..
My two semi-offtopic cents: I'd go for something that speaks IMAP (like VMime maybe?) :) A lot of the Maildir optimizations come free with IMAP servers like Dovecot (indexes, searches, fetching just headers or a partial body). You always have the option to just run dovecot locally to handle these for you and still have the Maildir locally (I use 'set tunnel="/usr/lib/dovecot/imap 2>/dev/null"' with Mutt).
To be honest I'm a little wary of introducing IMAP support, although I know it is the single biggest request I've had. I just know that with such complexity comes more coding and more potential for mistakes - things like verifying SSL certificates, dealing with network timeouts, dealing with logins and different authentication.
I've used VMime in the past and had .. mixed .. experience, which is another mark against the idea. It is unfortunate that there is no really "standard" IMAP client library out there.
I still think using
For reference this is the toy I've been working on recently:
As you can see the core is there but there is zero user-interface present. I think it would be easy to add the primitives that are missing and graft on the user-interface. I just need to decide whether the overhead/churn/upheaval is worth it. I suspect the answer is "Yes" but ..
I'm sorry for the lack of update on this issue, but work on lumail has been pretty much abandoned.
The good news is that there is a new project, lumail2 which is very similar to this one:
Why change? Lots of reasons, but primarily because I wanted everything to be an object: Messages, Maildirs, etc. The rewrite is more functional than the older-codebase, smaller, simpler, and much more flexible.
If you're still interested in Lumail please do take a look: