> 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 _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
