Re: Fwd: [ANNOUNCE] : Filters patch against 1.2.0 [e.allaud@wanadoo.fr]

[Brian Stafford <brian stafford uklinux net>]

On Tue, 25 September 23:12 Pawel Salek wrote:
> 
> On 2001.09.25 13:49 Brian Stafford wrote:
> >  Hmmm...using external programs isn't necessarily part of the philosophy.
> >  Its certainly traditional though that tradition started because the 
> >PDP-8
> >  original unix only allowed processes up to 8Kb in size.  Realistic
> >  programs
> >  had to be broken into many smaller ones.  Traditions are flexible, that
> >  is how they survive.  I don't think anyone nowadays insists that a
> >  program
> >  bigger than 8K is too big.  Similarly, I don't think that just because
> >  Un*x allows flexibility with multiple processes it means it is always 
> >the best
> >  solution to a problem.
> 
> While I agree that multiple processes is not always the best solution to a 
> problem, it is certainly always worth considering.

Agreed ...

> 1. having separate programs for separate tasks is more flexible. One can 
> have single program for address book edition, no matter if your MUA of 
> choice is balsa, evolution, mutt, pine, or spruce. or a combination of 
> them.

Agreed.  However it is also the case that many different programs must
carry out the same or similar tasks.  In these cases a shared library might
be more appropriate than a seperate program.  My point here is that external
programs are a valid way of doing things but there are other ways to solve
problems. We should not be dogmatic about Unix history and be forced into
always solving problems using the multiple programs approach.

However the point about sieve is that it defines a common syntax and semantics
for mail filtering.  The implementation is a secondary issue.  Multiple
implementations of sieve and multiple programs may use the same scripts.

> 2. your mail window does not go to valhalla when your www browser decides 
> to go there.

Indeed.  I am vehemently opposed to the idea of a single monolithic program
that does everything.
> 
> 3. in certain situations, it can replace multi-threading that would need 
> to be then coded by hand. (this is a valid argument as long as one does 
> [not] need to code IPC instead).

Also true.  I sincerely hope it is clear that I'm not implying that external
programs are wrong.

> Concerning procmail vs sieve, I think the syntax of the config file is 
> irrelevent as long as one aims to use GUI for its edition. I certainly 
> agree that sieve syntax seems more reasonable than procmail's.

I consider the syntax of the config file highly relevent which is why I'm
banging the drum for Sieve.  A well designed syntax for the file means that
it is easy to program specialised editors for it (GUI or not).  Commonality
of syntax means that multiple third parties can code implementations of it.
This can only be good.

> The issues that I think should be discussed:
> 1. should balsa filters be stored, or have an export option to sieve 
> syntax, to allow easy upload to remote mail servers?

I feel the best solution is to implement sieve directly.  Export as sieve
is a second best solution, however it might be a good transitional approach.

Given that sieve editors are starting to appear (try a freshmeat search!)
perhaps it should be considered whether filter editing should be part of
balsa at all.  "Edit Filters ..." should exec the external program ;) perhaps?

> 2. how can we stimulate usage of sieve server-side mail filtering?

MTA based filtering can be done only at the MTA which delivers mail for
a domain.  Therefore a sieve capable version of "deliver" programs that
sendmail et al. use to perform final delivery (procmail is in this category)
is the correct solution here.

> I think 
> availability of server side filtering is crucial.

Agree absolutely.  This facility is absolutely essential and should never
be omitted from a system (sadly it usually is).

> I use it now presently 
> to keep my primary inbox free from discussion list messages etc. I know I 
> could use balsa soon-to-be-available filtering to hide bulk mail from the 
> inbox but the fact is, I cannot always use balsa to access my mail for 
> various reasons.
> 
> Opinions?

Yes :)

Brian