Re: [Evolution-hackers] Filtering and mail split
On Thu, Dec 3, 2009 at 3:48 AM, Jonathon Jongsma jonathon.jong...@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 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Filtering and mail split
On Wed, 2009-12-02 at 19:23 -0500, Matthew Barnes wrote: The overall design of the filtering classes has always seemed a little backwards to me. We need to be generating rule element widgets from an S-expression, not generating the S-expression from rule element widgets. I have not studied the ESExp API very closely yet so perhaps it already provides what I'm about to suggest, but it seems like what's missing here is an Abstract Syntax Tree (AST). An AST is just a simple tree of nodes consisting of not much more than a type code and a string value. It's not bound to S-expressions or any other syntactic form. We would need the following capabilities: - Generate an AST from an S-expression string. (fairly complex, but maybe ESExp already does this?) - Build an S-expression string by walking over the AST. (dead simple) - Build an editing interface from an AST. (doable, but probably fairly complex -- never tried this) - Modify the AST to reflect changes in the editing interface. (should be simple if done right) I'm of the opinion that most of the XML filter definition should be junked, except perhaps for the partset stuff but that could just as easily be a GtkBuilder spec. A simple way to store the rules then is to save each rule to a separate file in a dedicated directory. Each file would contain an S-expression describing the rule, and the file name would be the rule name. We would also want to track the rule order in some kind of index file somewhere. The backend's job is pretty easy then. It just slurps up files from the agreed upon directory and also reads the index file for the rule order, and hands them off to the filter or search driver as necessary. (We really should be handing an AST off to the drivers, not an S-expression string. S-expressions would then become an arbitrary choice of storage format, and could be much more easily swapped out for something else if a standard ever emerges. But whatever.) The backend might want to also monitor the directory and index file for change notifications from the frontend and just re-slurp everything when something changes. The frontend's job is considerably harder, but I think most of the pieces are there already. They just need to be glued together different. I do have some experience at language parsing from a past life, so maybe I could be of some help here beyond just pitching lofty ideas from the peanut gallery. I like the concept in general, but I think the S-expression (or AST representing the s-expression) is not enough to properly re-construct a filter rule for editing. Consider the following example (yes, it's slightly contrived, but the point is still valid I think): User creates one filter with the following rule part: - Sender contains foo - evolution builds this into the following s-expression: (and (match-all (header-contains From foo))) User creates a second filter with 2 rule parts: - Specific Header From contains foo - evolution builds this into the exact same s-expression: (and (match-all (header-contains From foo))) If we only saved the s-expression to disk and then tried to build an widget to edit this filter, there would be no way to determine whether to use the 'sender' filter part or the 'header' filter part without some additional context. -- Jonathon Jongsma jonathon.jong...@collabora.co.uk ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Filtering and mail split
On Thu, 2009-12-03 at 20:35 +0530, Srinivasa Ragavan wrote: On Thu, Dec 3, 2009 at 3:48 AM, Jonathon Jongsma jonathon.jong...@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 Yes, it's a valid question. Let me quote one thing from my original mail that wasn't emphasized very well so you may have missed it: (note that when I say 'frontend', it may be the MUA itself, or it may be a helper client library like some future libedsmailui library): So my thought was that maybe we would have a libedsmailui utility library (similar to something like libedataserverui) that would implement these filter editing dialogs, etc. Then evolution and anjal could both use them by simply linking to this UI utility library. Does that address your concerns? -- Jonathon Jongsma jonathon.jong...@collabora.co.uk ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Filtering and mail split
On Wed, 2009-12-02 at 16:18 -0600, Jonathon Jongsma wrote: 3) Keep the filter classes in the frontend. The backend doesn't really need to know anything about potential values for elements or which FilterParts are combined together to generate the resulting S-expression. All it really cares about is the final S-expression. Unfortunately, to generate this S-expression from the saved filter XML files, you need to parse everything and then map the values found in the ruleset nodes to the elements in partset (the filter parts contain the rules for generating the s-exp code from the filter values, but the rule provide the values). We can avoid having to parse the entire XML tree if we save the full s-expression for each filter to disk along with the xml description of all of the elements that it is built from. Then the backend could simply load the name and s-expression for each filter at startup. The frontend would be responsible for parsing the full xml describing the filter types, and setting up the filter contexts like it currently does. When a user changed / added / removed a filter, the frontend would simply send the new s-expression associated with the named filter down to the backend (or notify the backend that it should be removed) and cache the new s-expression to disk for the backend to load on next startup. The drawbacks of this option are: a) it feels rather hacky, b) the frontend and backend still need to coordinate on where to load the files from. The overall design of the filtering classes has always seemed a little backwards to me. We need to be generating rule element widgets from an S-expression, not generating the S-expression from rule element widgets. I have not studied the ESExp API very closely yet so perhaps it already provides what I'm about to suggest, but it seems like what's missing here is an Abstract Syntax Tree (AST). An AST is just a simple tree of nodes consisting of not much more than a type code and a string value. It's not bound to S-expressions or any other syntactic form. We would need the following capabilities: - Generate an AST from an S-expression string. (fairly complex, but maybe ESExp already does this?) - Build an S-expression string by walking over the AST. (dead simple) - Build an editing interface from an AST. (doable, but probably fairly complex -- never tried this) - Modify the AST to reflect changes in the editing interface. (should be simple if done right) I'm of the opinion that most of the XML filter definition should be junked, except perhaps for the partset stuff but that could just as easily be a GtkBuilder spec. A simple way to store the rules then is to save each rule to a separate file in a dedicated directory. Each file would contain an S-expression describing the rule, and the file name would be the rule name. We would also want to track the rule order in some kind of index file somewhere. The backend's job is pretty easy then. It just slurps up files from the agreed upon directory and also reads the index file for the rule order, and hands them off to the filter or search driver as necessary. (We really should be handing an AST off to the drivers, not an S-expression string. S-expressions would then become an arbitrary choice of storage format, and could be much more easily swapped out for something else if a standard ever emerges. But whatever.) The backend might want to also monitor the directory and index file for change notifications from the frontend and just re-slurp everything when something changes. The frontend's job is considerably harder, but I think most of the pieces are there already. They just need to be glued together different. I do have some experience at language parsing from a past life, so maybe I could be of some help here beyond just pitching lofty ideas from the peanut gallery. Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
