Re: [Evolution-hackers] .mailfilter and/or Sieve support. And .spamassassin/user_prefs on server

[Rodney Dawes <dobey novell com>]

On Sat, 2004-11-20 at 14:47 +0100, Philip Van Hoof wrote:
> On Fri, 2004-11-19 at 13:09 -0500, Jeffrey Stedfast wrote:
> 
> > We plan to implement Sieve support at some point, but right now not
> > many servers actually support the feature so it's not a high priority.
> 
> A lot IMAP servers only support .mailfilter-like scripts (does courier
> have support for Sieve?).

I don't know if courier does or not. However, we don't have time to do
server-side filtering through sieve or anything else right now really.
Exchange may get it for 2.2, but I don't know what the feature targets
are for 2.2 in the Exchange Connector right now. They might not have
time to do it either.

> > We will not be implementing code to ssh into the server and edit files
> > directly.
> 
> Support for .mailfilter (and Sieve scripts, but there are Sieve-script
> deployment daemons afaik -I know it looks a lot like a POPd-)
> deployments on remote locations doesn't really sound like a difficult
> issue when using GnomeVfs. 
> 
> In stead of writing and reading the script from ~/.mailfilter, you'd
> read/write it from sftp://username server/.mailfilter. So it's just a
> preference for the advanced user.

This won't work. It depends on using some other method that most users
won't have access to. This means we'll have to have extra stuff in the
UI for the very few people that will have it. It also means we have a
lot more code to maintain. It may seem like it would be a trivial thing
to do, since gnome-vfs is modular and has support for a few protocols.
However, there's a lot more to making it work, than just telling
VFS that we want to put X in place of Y. Ideally, this needs to work
through the IMAP protocol.

> Which only leaves the need for a userinterface for the scripting-
> language (which is, of course, not trivial).

No. The filter interface needs to be the same for all methods. Whether
the filters are stored on the server, or locally, the interface needs
to be the same for both methods. Designing an interface around a
scripting language is bad. You either end up supporting everything that
you can do in the language, or nowhere near enough to make all of the
"advanced users" that use it, happy. If you do all of it, you end up
with a horrible interface, that only certain "advanced users" will
understand how to use. If you don't do all of it, you might end up
with an OK interface, but all of the "advanced users" will probably
get annoyed, because they can't use some arcane feature that they
must have in order to use the product. Redesigning the vfolder/filter
interfaces is one of the things that we are doing for the 2.2 cycle,
but we need to avoid trying to make it support everything, and then
designing it around that idea. We need to design it, and then fix the
backend to work with it and still be powerful enough for more advanced
users of the product.

-- dobey