Re: feature requests: edit message, pipe to ext. program

[Ray Morris <support bettercgi com>]

> Editing content makes me uncomfortable--it destroys a signature, for  
> instance, so you lose any authentication.  How about the ability to  
> add a note to a message?  It could be shown in the header box, much  
> the way signature info is shown currently.  A note might be editable,  
> or they could just accumulate, if you wanted to document progress in  
> handling.
>
> Annotation appears to be fairly easy to add to local mailboxes; some  
> IMAP servers support the ANNOTATE extension, which is designed for  
> this use, but some don't--they'd be more of a problem.



  I put some thought into that, too.  That could work.
I was thinking it would be best to keep it very simple
and not invent some new system for storing notes and
linking them to messages.  Instead, it seemed best to
me to keep eveything in the standard format it's already
in - mbox, mh, or maildir.  That would mean, probably,
adding the note as part of the message file.  If Balsa
were to mark it up with some sort of tag like <note></note>
and treat it specially that would be fine, but part of Balsa's
appeal, I think, is that it uses the simple and standard
mailbox formats instead of some one off database and I
wouldn't want to change that and make things more complicated
in order to add a fairly simple feature.  Balsa could
leave out anything marked up with <note></note> (or perhaps
a X-Annotation header) when computing a signature.


> As Pawel noted, the latest Balsa has the option to pipe the current  
> message through an arbitrary command (though as yet only on the  
> Message menu, not the right-click popup).  If you had multiple  
> messages selected, would you expect all of them to be processed?

  That would seem like the right thing to me.
If the user selects multiple messages and then
chooses the pipe option I can't think of what else
they would be likely to intend by doing that.
Certainly it makes more sense to process all selected
messages that to pick one at random, just do the
first one, or some other behavior.  This is consistent
with most of the programs I see in /usr/bin.
Most programs, it seems, when given mutltiple files
as arguments process them all.  So yes, I'd stick
a loop around the message open, output, message close
lines and do them all.

 BTW, I've learned this is a good general trick in
my own (Perl) software.  I look through my software
just looking for places to stick foreach loops.  It's
normally only a couple of lines of code to change
it so that instead of acting on one item (such as
processing one configuration file or having one
"admin" user) to have it work on as many items the
user desires and users love the extra flexibility.
--
Ray B. Morris
support bettercgi com

Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/