On Thu, Dec 3, 2009 at 3:48 AM, Jonathon Jongsma <[email protected]> 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 _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
