Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?")

[Randall Gellens <[e-mail]>]

> >I think we really need to focus on keeping the base spec simple, and
> >compatible with IMAP and ACAP.  The simplest way to store the filters in
> >ACAP would be as one attribute, in the user's options dataset.  That would
> >give you the explicit ordering you want, but would make it a bit difficult
> >for some clients to deal with very long sets of filters.  The other
> >approach I see is to store each filter rule in its own attribute.  Ordering
> >could be enforced by an extra attribute (execute-order) which would contain
> >a number.
>
> If anything, they should be in one dataset with 'sieve-filter' or some
>variant
> as the name.  If we have to do individual entries for individual rules, any
> sense of ordering or inclusion would become increasingly difficult.  Even
> if we keep such elements out of a first draft, you don't want to preclude
> them from a future draft.

I'd go along with either approach.  Personally, I think having each rule in
its own attribute is easier to manage, but it's not something I feel very
strongly about.

Here is what I think we need to get server-based filtering moving along:

(1)  A very simple filter language.  Minimal functionality, easy to
implement, with an extension mechanism.

(2)  A spec for how to store filters in ACAP.  If all of a user's filters
are stored in one attribute, it seems kind of silly to have a whole dataset
for it, but I don't really care that much.

(3)  A spec for how and when filters are to be executed, and what to do in
case of errors, unrecognized elements, etc.  Also, how to notify users of
the filter results (if such notification is desired).  Plus, how a delivery
entity advertises support of filter extensions.  It seems to me that any
unrecognized filter should result in default action (file in inbox).
Simple mail messages could be used for notification.  An IMAP CAPABILITY
keyword seems to make sense for advertising support of filtering (and
filter extensions), but does tend to blur the lines between the protocols a
bit.  But it seems the most logical place to start.