On Nov 10, 2009, at 8:37 AM, Uriel <[email protected]> wrote:
On Mon, Nov 9, 2009 at 11:49 PM, pancake <[email protected]> wrote:
Hello everyone!
I'm writing this lines because the delayed release of dmc that
was announced few mails ago.
The reason for the lagged release is because of the lack of time
to finish the design and implementation :(
We plan to release it before the end of the year ;) hopefully
before the end of this month.
The current status of the project is not to be released. I know
that many of you are interested in the code to start playing with
it, but I want to get a working proof of concept with mostly
decent code before pushing it to the community.
Nibble and me have been working on it and actually there's support
for:
Networking:
- plain
- ssl (no certificate check yet)
- no starttls support (but can be easily implemented)
Supported mail sources:
- pop3: 116 LOC
- imap4: 221 LOC
- mbox: 150 LOC
- mdir: 80 LOC
Attachments support:
- dmc-pack: handles packing/unpacking of attachments (150 LOC)
Addressbook support:
- dmc can read/edit a simple addressbook file
Multiple account support:
- Multiple accounts can be configured
Filtering:
- dmc-filter allows to filter body, and add/get/remove headers
from stdin. It is 63 LOC.
Tagging support
- dmc-tag: (120LOC) handles a database of files and tags. it
can get all tags matching N tags (AND op)
Sending mails:
- Only msmtp is supported atm. But !mail and native smtp
protocols will be supported at some point (0.2)
SLOCCount measures the project in 1262 LOC.
All those mail source applications understand unix-like commands from
stdin and throw status messages to stdout and command output body to
stderr. This way you can use them as shell applications or manage
them as daemons. (This is what 'dmc start' does)
I don't really think the project can bypass the 2kLOC limit, and
actually the whole project consists in 9 programs that interact
together using fifos and pipes. So it opens many scripting
possibilities, but enforces a centralized management using the
root 'dmc' program.
Some of those programs are written in C, and some other in
shellscript,
But the plan is to rewrite everything in C at some point.
The missing points before 0.1 are:
- standarized output for all protocol handlers
- basic unidirectional sync support for pop3/imap4
Syncronization methods are unidirectional and limited atm. We don't
plan to get everything working for 0.1 ;)
Sounds like an interesting project with potential so far...
In the future I want to manage online and offline accounts, thanks
to the daemons you can recycle a single connection along the time
or just use a local cache, so you can work offline and then resync
directories when you get online. All this information is stored
inside ~/.dmc.
What are 'online' and 'offline'
Online accounts are the ones with the contents are not cached and
directly accessed against the server. The offline will need support
for caching, syncronization... Offline accounts will be not that
simpler, but they are necesary. Not only for working offline.. Because
they will give you the possibility to work on accounts without having
to relay on timeouts or network cuts or slowdowns..
Mdir/mbox will be online by default. Unless you work with them
remotely there's no sense to cache them
accounts? And I don't see why a mail
client should depend on any daemons, unless it really makes much
sense, daemons should be avoided as they are clumsy to manage and make
software more fragile (among other things).
Yes, I was also thinking on removing the daemon stuff because it adds
some complexity and forces to add more checks, locks.. But ATM they
will be there. At least for testing.. At the end they are just a line
in shellscript.
I have also started to write a graphical interface. I have choosed
Gtk and Vala for it, but all the features will be accessible from
commandline.
Total complete double epic FAIL. This is completely unacceptable for a
suckless project.
This is a separate project from dmc. It doesn't plans to be suckless.
It just aims to be an usable frontend for desktop and maemo-like
environments.
At the end I just want a task schduler to run commands and handle the
io and lifecycle of those programs.
uriel
I don't plan to write a ncurses frontend at the moment,
but shouldn't be hard to do. (yeah I suck ;) but the gtk gui will
be keyboard friendly. I'm not sure how it will work with large
email boxes, but the mails can be automatically tagged to get reduced
views of the whole mail box.
I have attached the documents explaining the way how the protocol
programs can be used and another describing the GUI panel layouts.
Let me know your wishes and ideas.
--pancake
