On 2010-01-22, at 17:22 , Adam Engst wrote: > > On Fri, Jan 22, 2010 at 8:31 AM, Tim Gray <[email protected]> wrote: >> I wish Gmail would stop getting held up as the ideal. Gmail filtering is >> weak at best. Yes it's server side which is nice, but why can't I make a >> group of contacts in address book and filter for that group ? > > Gmail filtering is extremely weak on the criteria and the triggers, > but extremely powerful in that it's just another way of doing a > search. For instance, most email programs don't let you preview the > results of a filter, nor do they let you apply a filter retroactively > to every message you've ever received. That's tremendously powerful > and encourages experimentation, which I think is a good thing. I never > wanted to mess with my filters in Eudora for fear that I'd break > something else and end up with messages in wacky places. > > Search should be everywhere. And if the search isn't fast enough to be > everywhere, try again. ;-)
Indeed. I've been mentioning this recurrently in many threads, without calling particular attention to it, but: I believe applying filtering rules, in the most strict sense, shouldn't so much be the main focus, instead, everything is search, in the sense that everything is a live query. You may name a query, and create a smart folder that displays said results. With that, even plain folders can be implemented as the query for messages that are in the folder with that name. As you alter the conditions of a named query, you change the messages displayed in the smart folder that maps to that query name. It would be nice, too, if a named query can be used as a condition in other queries: say you have a view for "family" email, then you can create a second query like "in family && subject !~ /^Fw:/") (With that, tags would be the static equivalent. Once a message is tagged, it keeps the tag.) That impacts on filtering rules that have side-effects (rules that do more than saying where each message should go). E.g.: a plugin that posts support email to a bug database. We may leave that as a responsibility of the plugin, to check that it's not doing repeated work (but I wouldn't), or have a clear setting that for any given message, it's only called once. There are cases where it makes sense to run a plugin every time a match happens on a message. If a plugin has a script that prepares the messages content for a particular output, it'll have to run every time the message is displayed. (I would leave possible caching of the display to the plugin, as it'll be unnecessary in most such cases.) _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
