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. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
