Re: [dev] dmc news

On Nov 10, 2009, at 8:37 AM, Uriel <lost.goblin_AT_gmail.com> wrote:

> On Mon, Nov 9, 2009 at 11:49 PM, pancake <pancake_AT_youterm.com> 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
>>
>
Received on Tue Nov 10 2009 - 07:55:21 UTC