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

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 
>  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.

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 

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

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 
need to code IPC instead).

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.

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?

2. how can we stimulate usage of sieve server-side mail filtering? I think 
availability of server side filtering is crucial. 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.


Pawel Salek, Theoretical Chemistry, SCFAB, Stockholm

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]