Re: [Evolution-hackers] Re: [Evolution] Sieve support
- From: Philip Van Hoof <spamfrommailing freax org>
- To: Not Zed <notzed ximian com>
- Cc: evolution lists ximian com, evolution-hackers ximian com, Dan Winship <danw ximian com>
- Subject: Re: [Evolution-hackers] Re: [Evolution] Sieve support
- Date: 31 Jul 2003 18:39:57 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]