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

["Philip Van Hoof" <spamfrommailing freax org>]

> Ok.  So basing your code on the pop3 code probably makes 
> sense (although it might also be more complex than needed).  
> The nntp code is similar and simpler, although the pop3 code 
> was done afterwards, so is a newer design.  But it doesn't 
> need to be/shouldn't be done as a 'provider', for reasons above.


I have been working on converting this pop3 library to sieve and noticed
that I don't have to modify the concept. The concept of such a
sieve-storage is very much like a POP3-storage with the exception that
you can also PUTSCRIPTS to the storage. So perhaps it should not be
build as a camel storage provider, however, it can be and I am planning
to do this.

Aside from that it does not mean that once it's finished, you cannot
take the code out of the camel-tree and make it a standalone interface
for the SIEVE protocol. All the functionality the concept of a camel
storage provider offers is needed, because basically a SIEVE server is
nothing more nor nothing less than a storage for SIEVE scripts.

I would have liked it more if I could just send special crafted E-mails
to the SMTP that delivers E-mail to the IMAP-account to manage filters,
but this is not how the SIEVE script server facility works :-(

The benefits of using the camel storage interface is reusing sockets
code and a clean design. Is using camel a significant overhead or are
there other problems when using camel?

Perhaps using the lib located here
"/cyrus21-imapd-2.1.14/perl/sieve/lib" is also an option

-- 
Philip Van Hoof,  Software Developer @ Cronos
Work: Philip dot VanHoof at Cronos dot Be
Home: me at freax dot org
http://www.freax.be, http://www.freax.eu.org