On Fri, Apr 07, 2006 at 10:27:16AM -0500, Trae Dorn wrote:
Server side filtering is not available to many, and most desktop clients have the capability. Should it be a focus in RoundCube's development at the moment? Probably not - but long term I think client side filtering is a logical feature for RoundCube.
-Trae Dorn
Josh King wrote:
On Fri, 7 Apr 2006 08:35:06 +0800, "Derek Hinchliffe" iamplebian@gmail.com wrote:
I think Roundcube still has a way to go in some other more common areas of webmail functionality before anyone tackles filtering in a big way. But I would also question whether a webmail system is the right spot for mail filtering. This really should be done at the mail server level. That way the filtering occurs regardless of how you view your mail (eg. some days you might access it through Thunderbird, other days through Roundcube - you don't want to have to maintain two different sets of filters).
What is appropriate for a webmail client however is some sort of hook into that backend filtering system so that you have a nice way of configuring it within the webmail. An example that comes to mind is there is a plugin for squirrelmail that lets you manipulate sieve scripts on a cyrus backend. I am almost certain there would be a similar procmail one if you looked around.
So the best way would be to write the filtering interface as generically as possible, then write seperate backends for the various filtering systems around (procmail, sieve, etc).
But my main point is, in the meantime there is nothing stopping you from having filtering with your roundcube - it all depends on what mail system you use in the backend. You just have to configure it in there instead of having the convenience of doing it through roundcube.
Cheers Derek
Just my $0.02, but I would have to agree with Derek here. Adding filtering would, IMO, take RC from being a client to an LDA (local delivery agent) and could cause issues for those who already have this functionality handeled within procmail, etc. .
Focusing on being the most able webmail client and having some ability for plugins to be added to have this functionality would be much more preferable.
Looking this thread over, it seems that it may be best to do something along these lines:
Option 1: Build a plugin architecture Build a filtering interface on top of that Have different backend drivers for that filtering interface. Candidates would include procmail, sieve, maildrop, and roundcube-based filtering. The last would perhaps run when the user logs in or checks for new mail.
This is similar to how Horde handles filtering. A semi-separate application (ingo) handles filtering with a standard interface, and there are various backend drivers to choose from including filtering at by the webmail program itself.
Option 2: Build a plugin architecture Let people build filtering plugins for it.
This option is more like squirrelmail's handling. The avelsieve plugin driver I use with SM looks and feels much different than the procmail driver that is available. I think this option is simpler and probably more lightweight, but it is also less consistent.
Either option could allow one to write a filtering that is actually handled within RC, but could alternatively use whatever server-side filtering system is available to the user.