Re: Filtering

[Jeffrey Stedfast <fejj stampede org>]

On Tue, 25 Jan 2000, Jules Bean wrote:
> 
> On Tue, 25 Jan 2000, Jeffrey Stedfast wrote:
[snip...]
> > having to "shell out" costs more in resources than it would having it's
> own
> > filtering capabilities. 
> 
> Absolute rubbish.

explain? the way I see it, and correct me if I'm wrong, loading another
program *does* take more resources than if you had a few functions built in
because you wouldn't need a lot of the code that procmail uses to parse
config files, parse command-line options, etc, and you would also eliminate
procmail's "load" time (it's doubtful that it takes much time, but it still
takes time).
it may not be a whole lot of extra, but it would be more than it would be
if it were built in

bah, I dunno...

[snip...]
> 
> One program, one job, is the unix way.  And not without reason.  For
> example: if everyone who wants to filter mail --- not just balsa users
> ---
> uses procmail, then procmail will become enhanced with all the features
> people want.

now this I have to agree with

> 
> Having to 'shell out' costs virtually nothing. Also, procmail does the
> filtering at the 'logical' time - at mail delivery time, not at MUA load
> time.  If, for example, you haven't checked your email in a few days and
> have 1000 messages in your inbox to filter, that'll take a while.  With
> procmail, it's already filtered.

huh? who says Balsa has to filter at load time? Why not have it filter as
it pulls email back? That's how I do it (with spruce)
(Balsa has it's own POP fetch code right? If not, then ignore me)

> 
> All that having been said, there are a few arguments for filtering
> built-in to balsa:
> 
> Procmail's config files are genuinely unnecessarily opaque in design.  It
> is possible to have power without being that opaque :-)

now this I wouldn't know, so if you say so I'll take your word for it ;-)

> 
> Having the filtering in-balsa is more flexible for the case that your
> messages are physically distributed on a variety of systems -- in the
> procmail case, you'd need procmailrc's in every place
> 
> Having the filtering in-balsa allows better integration with balsa's
> other
> facilities, and would allow for some quite cool 'wizards' watching your
> normal mail-moving habits and guessing filtering rules.
> 
> 
> *however*
> 
> it's going to be hard to put a GUI onto a properly powerful filtering
> engine.  Intuitive GUIs for what are essentially procedural tasks are not
> properly understood.
> 
> Camel is on its way, and camel's vfolder stuff will sort-of supercede
> filtering, and camel will have some filtering capability built-in.
> 
> 
> All of which having been said: if someone wants to code filtering, do it.
> Just think about the above issues first!

in any event, I think filters are an important feature


> 
> Jules
>  
> 
-- 
Choosey moms choose Spruce!