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

[Carlos Morgado <chbm chbm nu>]

On Mon, Nov 12, 2001 at 10:32:51AM +1100, James McPherson - TSG Engineer wrote:

> 
> 
> Hmmm, now we're approaching the interesting set of features that Solaris' dtmail 
> has - for values of "interesting" which go from "fscking awful" to "really quite
> neat." 
> 
ehhehe

> dtmail uses $HOME/$MAILDIR/.<viewname>.index for keeping track of the matching
> messages that are currently in your inbox - dtmail "views" == balsa filters on a

keyword here is 'inbox'. if we only track 1 box it gets pretty simple :)

> virtual folder. I just ran strings over one of these index files -- it's totally
> binary and I have no desire to go through the dtmail code to find out how it is
> written out (apart from the company confidential thing).
> 
i'd say it's prolly a db file with headers/pointer. not really important
though.

> dtmail updates the views / virtual folders each time it grabs an updated index from
> your inbox, which can get very slow ;| even though I'm pretty sure that's another
> thread that's doing it. hmm, think there could be a locking issue with this. 
> 
yeah, it tends to be *slow*. for fun, try importing a large mbox into
evolution. (granted, evo indexes bodies too afaik)

> How about this for a way forward:
> 
> virtual folders to be updated on demand by the user -- either by explicitly requesting
> an update, or after moving (a) message(s) to disk-based folder / trashcan etc.
> 
yeah, there's no way around this :)
problem here is you get callback hell, with all messages reporting changes to 
a bunch of folders. or bring a registration type system back from the dead
and do a message rounting table (oh gar, that sounded like a buzzword :))
that's pretty much an hash/table of messages vs. views (oh - this is just
like gtk+ signal tables except you have to maintain it :))

> updates done with a separate thread, which _either_

this is hard. (errrr .. isn't it ? did my brain disconnect ?). this is hard
cause you have to do 'weak locking' to avoid keeping the UI from reaching
the mail backend. of course, you can always just let the views engine suck
the life out of the UI .. which kind of makes sense if the user is waiting
to a view to open

>    (1) also grabs the inbox so that the regular inbox checking gets postponed 

i take it works by fetching messages or polling 1 mailbox for new messages ?

> or (2) forces an inbox check, then locks the inbox and updates the virtual folders
> 
'sucking the life out of the UI' :)

> Of course, messages can be visible in multiple virtual folders - eg if I filter 
> separately on "to me" and "cc me" - something to be careful of. 
> 
oh yeah, that's one more degree of complexity for the 'has this view indexed
this message' problem

> If keeping an index on disk, what sort of file format would be needed? Berkeley db
> or plain text? I think Berkeley db - somewhat easier to read and parse quickly than
> plain text imho.
> 
berkeley db is QuiteEnough i think. it's there, it's proven, it's fast 

anyway, this means doing indexes. problem with indexes is don't quite know
how they interact with libmutt. prolly quite well, as they can be considered
a libbalsa thing.

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





























still there ?