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]