Re: [Evolution-hackers] Re: [Evolution] Sieve support

[Philip Van Hoof <spamfrommailing freax org>]

On Thu, 2003-07-31 at 17:53, Not Zed wrote:

> I'm not sure it really makes sense to copy any provider, or to implement
> it as a provider rather.  Providers provide objects to retrieve messages
> (stores), and/or send them (transports).  It really sounds more like a
> service provided on-top of a provider.  However it's done, it should

Yes, it's a service provided on top of a provider and that
camel-provider I am planning to build is only the low-level interface
for another more high-level interface (library) which I hope will be
build during the development of Exchange-script support by Ximian.


> probably integrate at least in some way with the existing filter stuff
> (even if that requires changes), e.g. through common interfaces/abstract
> superclasses, etc.

Indeed, thats why I decided to wait for the Exchange-filter support to
become finished. I am hoping that this abstraction-layer will be build
for the Exchange-filters in a way that it can be reused for other
scripting facilities -and languages.

> Only being very rough here trying to describe what I mean ... but
> basically some sort of OO design approach is desirable.


> Does sieve go over its own tcp connection then?  (sorry i haven't really
> looked into it for years).

Yes, well..

Sieve is only a programming language and has an interpreter deployed on
the IMAP-server. There is, however, also a protocol (and a daemon) for
deploying sieve-scripts. This protocol looks a lot like POP3:

- It connects on port 2000

- It  uses SASL authentication (I still have to figure out how to do
this correctly on the clientside)

C: AUTHENTICATE "type" "..."

- It has commands like
C: LISTSCRIPTS
S: "ScriptName"
S: OK
C: GETSCRIPT "ScriptName"
S: ...
S: OK
C: PUTSCRIPT "ScriptName"
C: if (..) {
C: }
S: OK
C: LOGOFF

So basically that means sending stuff and getting stuff like with POP3
;)

> I guess that basic idea is sound, although ... the 'library' could just
> be some camel objects, if you want it well integrated.  And that could
> be implemented more or less independent of whatever front-end api's are
> exposed.  So it would be a good place to start.

> I'd probably suggest in order, something like ...
>  - a more or less independent impl for handling sieve protocol
>  - some abstraction for rules, even if they're just opqaue text
>  - some api on CamelStore to get access to the rules on a given server

Indeed

[CUT]

-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
work: Philip dot VanHoof at cronos dot be
http://www.freax.be, http://www.freax.eu.org