[Evolution-hackers] filter refactor, rule parts

[Not Zed <notzed ximian com>]

While working on the idea of supporting server-side rules, i've come up
with an idea about changing the way the filter editor/definitions work. 
Although it could also be made backwards compatible too.

Currently, a rule part is built from a bunch of gui/value primitives
which are combined in various ways, e.g. a filter definition might
consist of an 'optionlist' followed by a 'text entry'.  We just save out
the value of each as the 'filter definition', and build an expression
based on substituting the values (or even selecting code fragments) into
an expression string.

I'm considering changing that to implement it as a 'filter type' with
values for that type.  And the code knows how to build the corresponding
expression directly.

The main difference here is that any changes to the filter types would
require a change to the code.  On the other hand, it would make it
easier to write coded plugins to implement new types, and might make it
easier to create different backends.

On the code side, a filter rule would consist of a list of FilterPart's,
and each backend would subclass FilterPart for each of its type of
parts.  FilterElement and all of its subclasses would no longer exist,
but instead you'd get a lot more FilterPart subclasses (and more new
ones than you're removing), and possibly less scope for code re-use.

Any thoughts?  Would it make exchange server-side easier?  Just been
looking at sieve ... and i'm not sure anything could map to that very
well, if custom scripts are used anyway.  imho we'll need to parse the
sieve directly, not try to store meta-data in comments.