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
