Re: [RFC] : New features (search, filters, virtual folders...)

[Emmanuel <e allaud wanadoo fr>]

On 2001.11.10 01:46 Carlos Morgado wrote:
[...]
> > 	* search functions : using the "matching functions" (we'll have
> 
> > perhaps to split the current API to have more flexible funcs) we can
> > implement a "classical" search func, ie search in place that is you
> enter
> > a matching rule, click the button and you are moved to the first (or
> last,
> > or next...) message matching this rule, but also we could have
> something
> > different : something like an "out of place" search, I think of a popup
> 
> > window with a list of message that match the rules, you browse it and
> > double-click on whatever message will let you see the message (eg it
> will
> > select the message in the mailbox, or simply open a new window that
> will
> > print the whole message like when you now double-click on a message in
> the
> > list; this should certainly be choosable by prefs).
> 
> "out of place" is the same as the next point as far as i'm concerned
> 'in place' can be implemented pretty much the same way, but it's a
> transient
> bindex and "out of place" may get saved across balsa incarnations
> 
> and then there is procmail style filtering, but that sounds easy :)
> 
> and then there is knowing what messages you already filtered and which
> are
> new ones for copy/move rules. this scares me.

Yeah, this one scares me too, and that's why I implemented automatic 
filtering upon reception only for pop3, because with pop3. For local 
mailboxes in general you could have filtered yet a message, already copied 
in another mailbox, but next time you'll filter it again (I think the only 
solution is to use a finer flag systems for messages : a flag indicating 
that filters have been applied to it; perhaps this is yet possible, I saw 
that libmutt flags are finer that balsa's, balsa has only NEW flag, but 
libmutt has new and unread flags, if I understand it well).

> > 	* virtual folders (I don't know Evolution but everyone speaks
> > about it, shame on me :) : as I have thought about it, it is a "fake"
> > mailbox, and, when you launch it, it will be filled in by all messages
> > (from one or several mailboxes) matching the rules you had set up. Also
> 
> 
> iirc evolution uses the neat-o mbox indexing system to do vfolders. i'm

What is this indexing system?

> not
> sure how they deal with invalidation and ugly stuff like that.
> for starters we could prolly calculate the vfolders on startup (oh that

Perhaps just when user open the vfolder, that will save a bit of cycles :)

> blows dead bears - and it's utter crap on imap) and then try to manage
> them
> when the mailboxes are changed (ref counting fun!)

A signal handler connected to "changed" signals coming from all mailboxes 
that interests the vfolder (but still we must have a way to indicate that 
these messages has yet been filtered, these not; but we can imagine that 
vfolder will just consist of "reference" to actual messages, whatever form 
this takes, so that based on this reference we could know which messages 
are actually new, that is they haven't been taken into account by the 
vfolder).

> > each message in the virtual folder will be like "symlinks" in file
> > systems, that is I think like the search func when double-clicking a
> > message in the v. folder you will be either moved to the actual
> message,
> > or the message will be pop-uped in a new window, or whatever other
> > possibility you can think of.
> >
> 
> la la la the joys of searching on imap boxes and constructing
> vfolders/virtual-indexes/whatever based on that.

Yes for remote mailboxes we should have a way to allow the user to tell 
vfolders if he wants that we load the remote messages or not.

> > OK here it is, comment, flame war, whatever welcome :) before I try to
> > code one or another.
> 
> dude, i talk too much :)
> 
> 
> --
> Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey:
> 0x1FC57F0A
> http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5
> 7F0A
> Win$ is the living proof of Murphy's Law
> _______________________________________________
> balsa-list mailing list
> balsa-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/balsa-list
>