Re: [Evolution-hackers] bounties

[Lee Revell <rlrevell joe-job com>]

On Sat, 2005-04-02 at 09:54 +0800, Not Zed wrote:
> 
> Hi Lee,
> 
> Well, many of the mail ones not marked as complete are almost complete
> or it is just paperwork that they're not.
> 
> e.g. mail notification applet is basically done (via dbus stuff)
> inling pgp is being worked on (i think)
> default mail app is just waiting for copyright assignment forms from
> beruit
> message disposition notification is just waiting for a couple of minor
> cleanups but is basically done
> 
> The message templates would be a nice feature.  It would be
> interesting if it could be done as a plugin - i.e. first a plugin hook
> needs to be written to give access to the editor at the right time,
> etc, then the plugin to actually implement it.  It *may* be possible
> to do this using the existing hooks, certainly a first-cut should be
> able to get at least something working for this, even if it isn't
> ideal.
> 
> It would be good to see if the plugin system is flexible enough to do
> it for a start, and then it would probably be a good place to look at
> lots of mailer-related code to do it.
> 

Thanks, I'll look at this one.

> If you have other interesting ideas they may be worth looking into
> too.  e.g. a backup tool would be nice, that exported all data into a
> versioned format/file, that could later be imported into this or other
> versions of evolution.  Some people have looked at various
> incarnations of this, but they mostly rely on nothing more than
> tarring up the files so far, or they don't backup configuration data.
> There are many other possibilities I am sure.

Well, if I weren't doing this for the money (or if there were a bounty
for it) the first thing I would fix is to make the "Unread Mail" vfolder
usable on a slower machine when there are thousands of unread messages.
This has been bugging me since at least 2.0.  I looked at it briefly,
and all I can tell from oprofile is that a lot of time is being spent
somewhere in libcamel, but didn't get much farther as I did not have a
debug build of that library available.  In general I found 2.2 to be a
big performance improvement over 2.0, except for this issue.

Another idea that Robert Love has mentioned several times on LKML is a
mechanism to catch so-called -ENOPATCH user errors.  The simplest
imaginable form would run the outgoing message through patch(1) and
check for a nonzero return value when it sees [PATCH] in the subject
line.  Eventually it could use a better heuristic to tell when the user
meant to send a patch.

Lee