Re: Wish List

[Tim Southerwood <ts doc ic ac uk>]

Hi

Balsa rocks - and I am hoping to roll it out to our users soon :-)

Comments on these ideas:

On 2001.04.18 16:21:08 +0100 PSRwebs wrote:
> 1) There need to be Settings options for
>     (a) word wrap. One should be able to set this for a particular
> length.

Gets my vote...

>      At the moment it seems you have explicitly to wrap each message and
>      have no
>      control over the length.
>     (b) Background and foreground colors.  There doesn't seem any way to
>      change these.  This is not just aesthetic - I find a white
> background
> quite
>      a strain on my eyes

Cute - gets a "cute" vote.

> 2) All URLs need to be clickable and this should open a browser of choice

"Very cute but not essential IMHO" vote. 

> 3) Balsa needs an easy way of filtering messages into folders on arrival.

Hmm. I've thought long and hard about this. Here we let users
do what they like - lots use procmail, lots use exim's filtering
rules in a .forward file (which IMHO works better). I dare say
some do really *weird* things... Users (including me!) *do*
make mistakes sometimes in modifying filter files which then
causes problems... 

And then there's the home user who, unlike old nutter me doesn't
necessarily want to run a mail server on their box...

In the spirit of non-specificness, I vote for a plugin interface 
supporting only reasonably *generic* rules.
eg:

Matching of certain headers can:
1 - Bounce mail to another address
2 - Store into another mailbox
3 - get /dev/nulled.
and not much else. Actions are chainable so message 
can be bounced and stored locally.

One specific thought... How about a filter-rules GUI in balsa
and a perl plugin interface for handling the grunt-work? If mail
"delivery" is done by Balsa (eg fetch from POP) then the message
handling code could have a hook to the perl plugin which makes 
writing a local filter possible and easy.

I'm thinking of something like:

1 - User states filtering rules to the Balsa Filter GUI
*in a single generic way* irrespective of plugin.

2 - GUI calls perl plugin of choice with an array of filter rules. 

3 - Perl plugin of choice can write whatever system filter file
it likes.

With "internal" filtering (for POP/IMAP users with no procmail 
or similar option) then a perl plugin gets called for each incoming mail
(and possibly outgoing). Perl plugin loads filter rules
and deals with the message in a way appropriate to the system.
Rules and plugin are cached in memory after first use.

Then, perl plugin modules are needed for say:
1 - writing a procmailrc
2 - writing an exim filter .forward
3 - "internal" delivery to mbox files
4 - "internal" delivery to MH dirs.
and whatever else.

Maybe 3 and 4 should callback to Balsa which already has code to
mode messages between mailboxes...

Sysadmins like me can very easily tweak or reasonably easily write
modules to handle site specific needs.

Perl plugins worked for gimp - it can work for balsa...

Cheers and good luck.

Tim
-- 
Tim Southerwood
CSG, Dept of Computing, Imperial College, London
Email personal: ts@dionic.net work: ts@doc.ic.ac.uk
Tel home: 020-866-17388 mobile: 07949-487179 work: 020-759-48392