Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lumail 2 - Request for comments/suggestions/feedback #236

Closed
skx opened this issue Nov 22, 2014 · 11 comments

Comments

@skx
Copy link
Contributor

commented Nov 22, 2014

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:

  • Maildirs
  • Messages

I've written some stub code which works well, as a series of (C++) plugins:

   shelob ~/git/lua-plugins $ ./driver |head
   Loading plugin: file.so
   Loading plugin: maildir.so
   Loading CMaildir test
   /home/skx/Maildir/.tldp exists.
   CMaildir test complete.
   /home/skx/Maildir/.tldp has 3 messages 1 new.

In terms of implementation it is cute to be able to load functions from .so files, but I suspect that won't be used. Having lumail be monolithic hasn't hurt us so far, at least not that I can see. Using static code will allow cross-references too - for example a CMaildir object should return a CMessage object - and so it needs to know linkage types.

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.

@skx

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2014

So to start with then the following are obvious functions we need:

  • m = CMaildir.new( "path" )
    • m:path() - Return the path.
    • m:unread() - Count unread mails in the folder.
    • m:total() - Count total messages in the folder.
    • m:exists() - Does it exist?
    • m:create() - Create.
    • m:delete() - Remove.
    • m:messages( "all|unread|new" ) - Return CMessage objects appropriately.
  • c = CMessage.new( "path" )
    • c:header( "From" ) - Get the sender of the mail
    • c:headers() - Get all headers, and values
    • c:attachments() - Get all attachments
    • c:mark( "new|read|important|etc" )
    • c:flags( "new flags || undef" )
    • c:delete()

I suspect that's enough to replicate the current functionality, but there are some changes. We no longer have "count_attachments()" and get_attachment(3) instead we just return an array of CAttachment objects.

Similarly c:headers() would return an array of CMessageHeader objects - eahc of which has a "name" + "value" attribute. Though in this case header-reading is so common we'd add an accessor so you could run:

 c:header( "Subject" )
 c:header( "Date" )
@skx

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2014

@jugglerchris

This comment has been minimized.

Copy link
Contributor

commented Nov 22, 2014

Hi,
My thoughts as someone coming to lumail as a mutt user looking for "flexibly scriptable" rather than "thousands of options for many specific use cases, which inevitably is not quite what I want"...

UI:

  • I like the modal UI (the main maildir list/message list/message/text).
  • The text mode is just flexible enough for general mini-UI use (eg maildir chooser with completion etc.)

Scripting:

  • I think I basically agree with the above.
  • Some things I'd maybe do slightly differently to how they are now, but can live with as long as the functionality's there:
    • Instead of something like c:header("Subject"), I'd ideally make it look more like a Lua table, like c.headers["Subject"]. However, having said that, I guess it doesn't work for headers as the name is (I think) case-insensitive, so maybe ignore that one.
    • Definitely style, but I'm not a fan of functions which get or set depending on whether there's an argument. :-)
    • As far as integration with C++ code, I'd prefer setting key bindings (or other events) as a Lua callable rather than a string that gets eval()ed.

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."

@skx

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2014

Thanks for that - looks like our updates just crossed mid-stream.

Don't talk about mbox files though ;)

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 headers() method which would work like all_headers() does at the moment. But it would be a property of the Message-object rather than a global function.

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 ..

@paravoid

This comment has been minimized.

Copy link

commented Nov 23, 2014

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).

@skx

This comment has been minimized.

Copy link
Contributor Author

commented Nov 24, 2014

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 mbsync or imapsync, or similar is the simpler way to go. But maybe I could pretend networks are instant, reliable, and use some indirection to allow things to be swapped out behind the scenes.

@trou

This comment has been minimized.

Copy link
Contributor

commented Nov 24, 2014

Although I only use lumail from time to time (TB is still my mail client), I too think IMAP support is going to be too complex for the current state of the project and will result in way more bugs (when someone will try to use it with MS Exchange ?).

@jugglerchris

This comment has been minimized.

Copy link
Contributor

commented Nov 26, 2014

So does this mean there are significant changes about to appear, and that I should hold off on things for a bit? :-)

@skx

This comment has been minimized.

Copy link
Contributor Author

commented Nov 26, 2014

There might be a new repositor in the future, but for the moment there are no changes.

Just work, or not, as you see fit, just as you did before :)

@skx

This comment has been minimized.

Copy link
Contributor Author

commented Dec 5, 2014

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 ..

@skx

This comment has been minimized.

Copy link
Contributor Author

commented Dec 22, 2015

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:

  • It is still console-based.
  • It still operates solely on Maildir hierarchies.
  • It is still written in C++, with all the scripting support provided by Lua.

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:

@skx skx closed this Dec 22, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.