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

[Not Zed <notzed ximian com>]

Sieve scripts != email, stores are for storing email.  You're going to
have to implement a folder abstraction and a lot of other crap if you
want to do it this way, and it just isn't the correct way to do it.  And
pop is not sufficient, as it is merely a download system, you on the
other hand need a way to append messages (which must be in an unordered
fashion) and the like.

The only code re-use you're getting is cut and paste of the pop code,
all of the meat of the auth/socket stuff is in other classes.


On Fri, 2003-08-01 at 03:00, Philip Van Hoof wrote:
>  > 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