Re: [Evolution-hackers] bounties

[Not Zed <notzed ximian com>]

On Sat, 2005-04-02 at 00:33 -0500, Lee Revell wrote:
> 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

Oh that's a pity, bounties were just meant to generate some developer interest, not be a process of payment for volunteer work.  I'm not sure it was very effective at generating this interest in the long-term, so i'm not sure we will be doing too many in the future (I could be wrong however, that is only my own opinion).

> 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.

Well you can't do much without a debug build anyway.  FWIW there should be nothing different with that than any other vfolder either, so perhaps you've found some degenerate usage case for vfolders in general.

> 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.

I have no idea what "so-called -enopatch user errors" are.  It sounds a bit specifically un-related to general evolution mail usage however, or a generally-useful feature for normal users.  Maybe could be done with an outgoing filter + script, although at that point the mail is already sent.