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

[Carlos Morgado <chbm chbm nu>]

On Sat, Nov 10, 2001 at 11:08:04AM +0100, Emmanuel wrote:
> On 2001.11.10 01:46 Carlos Morgado wrote:

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

i'm not sure if this will hold for imap. don't some imap servers look at
flags or somesuch ?
libmutt knows about 6 or so flags

> > > 	* 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?
> 

binary indexes of regular mbox files. basic ripoff of jwz's indexing system
for netscape3 + some sort of content indexing for searches.
in a nutshell, you make records with message headers (whatever you need for
display/threads) and offset pointers to the mbox file.
there is been talk on and off to implement this on balsa, but neve happened.

> > 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 :)
> 
hum, yeah. i was thinking 'how basic can you start with' :)

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

hum. sounds like the registration system. didn't we get done with that on 
0.8 ? :)
anyway, you mean from all the messages that interest the vfolder right ?
something like reparenting messages would totally rule here, but we can't. 
maybe, moving some responsability to libbalsamessage ... 


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

you need to know which messages are old to each vfolder. god, all views must 
know all messages ? garrrrr
all messages know about all vfolders ? k .. this sounds worse :)

> 
> > > 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.
> 
definitly! we even have options not to check imap boxes for new messages. 

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