robert burrell donkin wrote:
>
>
> i've never liked the SIEVE format. it seems too easy to make mistakes
> and not at all human readable. i've done some reading and the
> reasoning behind this seems to be that SIEVE was intended to be a
> machine generated format and that users would use a GUI to create
> SIEVE scripts.
>
> so as a server side filtering option, it has drawbacks. a few
> things strike me:
>
> 1. it should be possible to create an xml language which can be
> checked against a schema and which can be transformed into a SIEVE
> execution script. there are plenty of UIs out there for xml.

I'm sure that Joe user will find both Sieve syntax and XML too high a
technical hurdle to clear without a GUI!

Here we are a looking at putting the infrastructure in place to run the
Sieve script that a GUI or some other mechanism might provide. As I said for
logging, being file based is fine. The use-cases for how the Sieve script is
developed and delivered are worth exploring, but lets not get distracted and
concentrate on the infrastructure first.
>
> 2. jochen's code is well factored: it should be easy to separate the
> filtering from the SIEVE implementation. maybe james could support a
> common filtering interface and allow any compliant mail filter to be
> plugged in.

I addressed this in a note to this list regarding the new Mailet API (also a
mail filter) about a week ago. I need to eat now, so you will
have to search the dev list.
>
> 3. a web UI is probably needed before it's realistic to expect
> non-developers to use this feature.

See (1). Also, some do exist. No idea of the quality.
>
> opinions?
>
> - robert
Cheers

-- Steve


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to