dmc

dynamic mail client
git clone git://git.suckless.org/dmc
Log | Files | Refs | README | LICENSE

wipmail3.txt (3957B)


      1 The current state of my minimalist email solution is quite hacky and incomplete
      2 but is starting to be functional and usable. I plan to publish the hg repo where
      3 the source is being developed in a week or two..
      4 
      5 Actually I have a pop3 implementation in 100 LOC and imap4 in 130LOC, for
      6 smtp i have delegated the task to msmtp (i will write the smtp protocol later),
      7 and a main shellscript that manages all the rest. this will rewritten to C at
      8 some point. But actually i want the functionality.
      9 
     10 pop3/imap4 works on plain and ssl connections by using nc and openssl. No
     11 extra security checks (like IP and certificate changes), but this will be done soon too.
     12 
     13 There is no decent syncronization mechanisms, just basic folder fetching from
     14 pop3 and imap4. For the attachments Nibble will write a mime packer/unpacker,
     15 so this will be about 100LOC more.
     16 
     17 At the end I think that the first working version will be about 1000LOC, but
     18 the code can be easily improved and cleaned up. But ATM i'm priorizing the
     19 functionaility.
     20 
     21 About threads I think the best way is to grep for a subject and sort by date.
     22 The problem I see in threads is that you loss the timeline and for long threads
     23 you get just lines (no text) because of the recursively nesting nature of the
     24 threads. If you want to 'ban' somebody comments, its just another grep filter
     25 to the list, etc...
     26 
     27 I don't plan to add threading support at the moment, just plain and filtered lists.
     28 
     29 The code of 'dmc' the 'dynamic mail client' that im actually writing is going to
     30 work only on *nix-based systems (no plans for w32 atm)
     31 
     32 About functionalities I dont want to chop any of them, but I want to keep the
     33 core as simple as possible, keeping the configuration minimal, and make the
     34 core actions enought to be extended by user scripts.
     35 
     36 About the frontend..well i would like to write a simple gtk-based GUI, but it
     37 will relay on the core dmc. So it will be plain simple to write web based interfaces,
     38 commandline ones, or whatever.
     39 
     40 There's a long way to go, but half of it is already known :)
     41 
     42 --pancake
     43 
     44 stanio@cs.tu-berlin.de wrote:
     45 > * markus schnalke <meillo@marmaro.de> [2009-10-18 10:17]:
     46 >  
     47 >> [2009-10-15 21:47] stanio@cs.tu-berlin.de    
     48 >>> Well, I can't tell which view is more useful in mutt -- threaded or
     49 >>> timeline. Which is proved by the fact that I have changed couple of times
     50 >>> in the past the default view from one to another, and switched views at
     51 >>> least once a day anyway.  Which proves for me that they are equally useful
     52 >>> for different tasks: [...]
     53 >>>       
     54 >> IMO threads are very useful for mailing lists. (With nmh, I really miss
     55 >> them there.)
     56 >>
     57 >> The inbox, in contrast, is best sorted by time, I think.
     58 >>     
     59 >
     60 > I need both views in both cases. With threads, in general, you can't see
     61 > the most recent posts overall. Even if you collapse them, all threads don't
     62 > necessarily fit in one page.
     63 >
     64 > Date sort alone hides the structure of a conversation, as long as
     65 > conversations tend to fork sub-themes, which is often the case with people
     66 > worth communicating with :o)
     67 >  
     68 >>> In summary: I would love a less sucking alternative to existing mail
     69 >>> clients, in nmh style, i.e. a collection of tools to handle different
     70 >>> aspects of the mail processing and to delegate non-mail tasks to $EDITOR,
     71 >>> grep, whatever. But there are some features I consider crucial, e.g.
     72 >>> decent unicode support
     73 >>>       
     74 >> Would it be so much work to add it to nmh?
     75 >>     
     76 >
     77 > I think it is not that big deal. I did it for a Win32 application at work
     78 > couple of years ago. But still needs time... And I am by far not the god of
     79 > code anyway.
     80 >
     81 >  
     82 >>> IMHO it doesn't make sense to cut things which serve you good tens of times
     83 >>> every day.
     84 >>>       
     85 >> It's not about cutting out stuff, but switching to the Unix style. ;-)
     86 >>     
     87 >
     88 > Agreed.
     89 >
     90 > If it's good, (it's unix style) XOR (it's illegal, OR immoral OR it makes you
     91 > fat).
     92 > :o)
     93 >
     94 >
     95 > cheers
     96 >   
     97 
     98