Re: [Evolution-hackers] Filtering and mail split

[Matthew Barnes <mbarnes redhat com>]

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