Re: [Evolution] Ramblings, feature requests, what if's

On 03 Apr 2001 22:03:23 -0700, Brian Lalor wrote:
Good evening, all.  I'm in a bit of toy overload at the moment.  New
laptop, new cell phone, and a couple of other new tidbits that are
keeping me on my toes trying to stay organized.

I've succeeded this evening in getting Evolution in a state that I find
usable, to an extent. I'm sucking down mail from my main IMAP server
with fetchmail, backing up messages with procmail, and letting Evolution
sort them into folders.  Provided I've got my sendmail configuration
cobbled together enough where I can send mail without screwing things up
royally, I'm in good shape.

God that sounds a total mess.

My only real reservation about using Evolution at the moment is that I
can't see where I can interact with the mail data in any way other than
using Evo.  For example, I'd like to be able to use pine if Evo is
unusable, and archive messages automatically using some kind of external

What happens if I modify ~/evolution/local/Inbox/mbox when Evo's
running?  When its not?  Will the folder summaries get rebuilt without
screwing up the data?  Can I add and delete folders under local (or
anywhere else, for that matter) and have the changes be recognized by
Evo?  Is there a way I can have something (a perl script, for example)
modify one of the mbox files while Evo is running, perhaps by locking
the file?  I'd like to archive sent messages on the first of each month,
but without regard to whether Evo's running at the time or not.

You should be able to do the following:
 - edit/change the content of mailboxes while evolution is running or
not, but only if the mailer locks the mailbox properly (elm doesn't for
any mailboxes it visits, for example).  The summaries *should* fix
themselves up, but sometimes they can get confused a little.
 - create/remove/renamed/copy folders, while evolution is not running
ONLY.  If it is, it will get very confused.

Well ideally we'd like to have scripting abilities to do all stuff

How modular is the mail transport back end?  Thus far, we've got mbox,
pop, imap, and probably a couple of others.  How difficult,
conceptually, would it be to write a MySQL backend?

Very, at the very leas you need just a 'get message' 'save message'
thing, but you really also need more for searching to work/etc (although
there are lot of reusable helper classes for this).

A basic sql backend would probably be a day's solid work, and a week to
get most features in there.

Is it possible to have an option whereby *all* outgoing mails are GPG

Think that's it for now. Just wanted to get a couple of things out.


Brian Lalor
blalor hcirisc cs binghamton edu, among others...

evolution maillist  -  evolution helixcode com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]