dynamic mail client
git clone git://
Log | Files | Refs | README | LICENSE

commit e03c6f8dda2481bbf697b739032b990198a5031d
parent 49626548e89ca0c269c8820501a3ef3cd5cc2b90
Author: pancake@flubox <unknown>
Date:   Tue, 20 Oct 2009 19:11:30 +0200

* Added wipmail3
doc/wipmail3.txt | 98+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 98 insertions(+), 0 deletions(-)

diff --git a/doc/wipmail3.txt b/doc/wipmail3.txt @@ -0,0 +1,98 @@ +The current state of my minimalist email solution is quite hacky and incomplete +but is starting to be functional and usable. I plan to publish the hg repo where +the source is being developed in a week or two.. + +Actually I have a pop3 implementation in 100 LOC and imap4 in 130LOC, for +smtp i have delegated the task to msmtp (i will write the smtp protocol later), +and a main shellscript that manages all the rest. this will rewritten to C at +some point. But actually i want the functionality. + +pop3/imap4 works on plain and ssl connections by using nc and openssl. No +extra security checks (like IP and certificate changes), but this will be done soon too. + +There is no decent syncronization mechanisms, just basic folder fetching from +pop3 and imap4. For the attachments Nibble will write a mime packer/unpacker, +so this will be about 100LOC more. + +At the end I think that the first working version will be about 1000LOC, but +the code can be easily improved and cleaned up. But ATM i'm priorizing the +functionaility. + +About threads I think the best way is to grep for a subject and sort by date. +The problem I see in threads is that you loss the timeline and for long threads +you get just lines (no text) because of the recursively nesting nature of the +threads. If you want to 'ban' somebody comments, its just another grep filter +to the list, etc... + +I don't plan to add threading support at the moment, just plain and filtered lists. + +The code of 'dmc' the 'dynamic mail client' that im actually writing is going to +work only on *nix-based systems (no plans for w32 atm) + +About functionalities I dont want to chop any of them, but I want to keep the +core as simple as possible, keeping the configuration minimal, and make the +core actions enought to be extended by user scripts. + +About the frontend..well i would like to write a simple gtk-based GUI, but it +will relay on the core dmc. So it will be plain simple to write web based interfaces, +commandline ones, or whatever. + +There's a long way to go, but half of it is already known :) + +--pancake + wrote: +> * markus schnalke <> [2009-10-18 10:17]: +> +>> [2009-10-15 21:47] +>>> Well, I can't tell which view is more useful in mutt -- threaded or +>>> timeline. Which is proved by the fact that I have changed couple of times +>>> in the past the default view from one to another, and switched views at +>>> least once a day anyway. Which proves for me that they are equally useful +>>> for different tasks: [...] +>>> +>> IMO threads are very useful for mailing lists. (With nmh, I really miss +>> them there.) +>> +>> The inbox, in contrast, is best sorted by time, I think. +>> +> +> I need both views in both cases. With threads, in general, you can't see +> the most recent posts overall. Even if you collapse them, all threads don't +> necessarily fit in one page. +> +> Date sort alone hides the structure of a conversation, as long as +> conversations tend to fork sub-themes, which is often the case with people +> worth communicating with :o) +> +>>> In summary: I would love a less sucking alternative to existing mail +>>> clients, in nmh style, i.e. a collection of tools to handle different +>>> aspects of the mail processing and to delegate non-mail tasks to $EDITOR, +>>> grep, whatever. But there are some features I consider crucial, e.g. +>>> decent unicode support +>>> +>> Would it be so much work to add it to nmh? +>> +> +> I think it is not that big deal. I did it for a Win32 application at work +> couple of years ago. But still needs time... And I am by far not the god of +> code anyway. +> +> +>>> IMHO it doesn't make sense to cut things which serve you good tens of times +>>> every day. +>>> +>> It's not about cutting out stuff, but switching to the Unix style. ;-) +>> +> +> Agreed. +> +> If it's good, (it's unix style) XOR (it's illegal, OR immoral OR it makes you +> fat). +> :o) +> +> +> cheers +> + +