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"
<[EMAIL PROTECTED]> 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.
--
Steve Block
http://ev-15.com/
http://steveblock.com/
[EMAIL PROTECTED]
