Re: [Evolution-hackers] Filtering and mail split

[Srinivasa Ragavan <sragavan gnome org>]

On Thu, Dec 3, 2009 at 3:48 AM, Jonathon Jongsma
<jonathon jongsma collabora co uk> wrote:
> As some of you may know, I've been looking into moving mail down to the
> e-d-s level.  As a first step, I'm figuring out where to draw the line
> between the front end and backend.  At the moment, I'm focusing on
> filtering.  I think that the filtering functionality clearly belongs in
> the backend (we want to filter emails as they come in regardless of
> whether the UI is running or not).  The thing I'm trying to figure out
> right now is what that means for the filter-related classes within
> evolution (i.e. the stuff in the filter/ directory).  My first instinct
> was that these classes belonged in the backend since that is the part
> that should be doing the filtering.  However, as I looked at it more, I
> wasn't so sure, and I'd really appreciate insight from people who might
> have a longer history with this code than I do.  (FYI, while I was
> getting more familiar with the filter code, I wrote up some
> documentation that you might find helpful:
> http://live.gnome.org/Evolution/Filters)
>

Excellent job in documenting it. Even more great, because you kept it at lgo.

I'm not gonna suggest one of the below but I'm going to think aloud,
shut me if its crap. Why should the UI be from the frontend, the
Evolution ? If my mail runs in EDS, which reads filters from a xml
file, may be as a small capplet/lib/bin  with the backend with the UI
to launch the filter manager. Independent of Evolution, may be Anjal
directly can launch it. Or if we have account setup from Control
center as a capplet, then we could launch the filter/rule manager
independent of Evolution itself. Is that too much to ask for?
It could simplyfy everything? Do we have a tight need of any Evolution
components for Filters? I just don't remember, but even if there is,
we should try to have it like this IMO

-Srini