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

[Not Zed <notzed ximian com>]

On Wed, 2003-07-30 at 16:08, Philip Van Hoof wrote:
> On Sat, 2003-07-26 at 18:41, Philip Van Hoof wrote:
>
> > I want to know if somebody is taking a look at support for Sieve
> > serverside IMAP filtering scripts in Evolution and/or if it's perhaps
> > already supported at this moment in a development branch.
>
> Trying not to put myself in the wrong direction I decided to ask about
> this:
>
> Am I correct if I say that /camel/providers/pop3 is where the POP3 stuff
> is located? While I was reading the RFC of the sieve-protocol

Yep.

> The question is, am I missing something? Shouldn't I start with copying
> the pop3 provider for some reason? (Is there a better library in the
> makes perhaps?)

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
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.

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

> My plan/idea is to first create a library (like the protocols pop3 and
> imap have) for the sieve protocol, then implement a very basic and
> simple GUI (for example to get a list of all scripts, to delete a script
> to add a script) and then fully integrate stuff with the filtering GUI's
> of Evolution. Because I have a daytime job I suspect that by the time I
> finish everything, the Exchange-filter support will have been added by
> Ximian (meaning that the GUI's are the way the smart guys of Ximian want
> it). I am hoping to then use that sieve-library of mine with some simple
> GUI-modifications to the Exchange-filter support.
>
> Does this sound like a good plan/idea? 

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

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

> Note that I do have a CVS-account on gnome but I will not be committing
> anything to CVS before sending a (huge) patch-file to the mailinglist
> and a strict "okay"-answer from the main developers of Evolution. 

Nod.  Note that we require copyright assignment for non-trivial patches
(if you haven't already).

> Also note that if I will be the only person working on this
> implementation, it will not be finished anytime soon (plus, I am also
> working on a few other opensource projects as hobby). Again, are there
> other people here who share the same idea and perhaps want to join the
> effort of getting sieve supported in Evolution? (After looking at the
> sources in filter/* I don't think that it's a impossible nor difficult
> job. The sieve-protocol looks pretty easy and is very well documented).

Hopefully someone can help here.

> ps. Evolution is a huge animal to get compiled. Are there tips/hints for
> getting modules compiled and-or installed faster? I know that I don't
> have to do `make clean` everytime, still it takes pretty long for the
> build-scripts to complete everything. Even on my SMP-machine. If not, I
> guess distcc will be an option (but I fear that it's mainly linking
> thats taking long, and afaik does distcc not distribute link-jobs)

Some of the bits can be made/installed separately, e.g. you can
build/install camel (or even an individual provider) separately and it
will be picked up automatically.  That only takes a few seconds.  Having
an up-to-date development environment (libtool, etc) seemed to make it a
little quicker, but on the other hand i keep getting faster machines too
often.

Regards, 
 Michael