Re: RFC mailbox interface

[Carlos Morgado <chbm chbm nu>]

Em Sex, 23 Nov 2001 00:48:05 M . Thielker escreveu:
> On 2001.11.23 01:02 Carlos Morgado wrote:
>> if a message is in 2 diferent folders with backing stores (ie. *real*
>> mailboxes) it's 2 diferent messages. a folder with a backing store is a
>> real mailbox for the user.
> 
> Wrong. It's a real mailbox for the user, and each of these contains an 
> identical copy of the message. It's still only one message to me, stored in 
> 2 different places. Which I access depends on performance....

That doesn't register for me. If i have a message on 2 separate mailboxes
and i delete it from one i fully expect the message to exist on the other one

> Opening the message from a remote folder, I would go ahead and load the 
> local copy instead...
> 
that should be transparent to the user

>> this whole virtual and vfolders and cache and backing store thing got well
>> out of hand. a folder with backing store is a mailbox. it uses space on 
>> disk.
>> it lives somewhere. it's backed up. the user cares about it. a vfolder/view
>> doesn't ocupy space on disk. if the message is copied to a diferent mailbox
>> it's a totally diferent message.
> 
> I don't see it that way. It's the same message as long as it's fingerprint 
> is the same.
> It's just _one_ message, stored in 2 locations.
> 

as i said above, it exists independently on the 2 mailboxes. i can see the
benefits of having the message flags shared. if i edit the message on one
mailbox (say, remove a stupid attachment or add a note) i don't expect
that to happen on the *other* mailbox

>> this is simple enough and can be used for mostly anything.
>> 
> 
> It would be simple, too, but doesn't allow for the performance increase 
> offered by the concept of treating all copies of a message as the same one 
> message rather than having each lead it's own life.
> 
you're thinking about the performance increase from caching ? or the
"access fastest copy" thing ? 
honestly real caching makes much more sense to me than message referencing
and copy-on-write shenanigans(sp? is there a sp ? :))
mostly cause it can be neatly on a separate layer, and cause it's so
much easier.

>>> Also note that the load_message wrapper (the main load_message function 
>>> of the lib) can use the information found in the _Foldertype structure to 
>>> assess the proximity of a server and prefer the fastest one to load the 
>>> message from, e.g. local maildir/mh first, local mbox second, IMAP on the 
>>> same subnet third. other IMAP fourth.....
>>> 
>> except if you're on UFS. or NFS. or samba. or some weird condition that
>> changes everything.
>> 
> 
> Well, it's possible to find out. As a matter of fact, if I were to write 
> this, I would gather perf stats while opening the mailbox and reading the 
> headers, then assign "speed indices" to each...
> 

clever. except it doesn't work for nfs :) 
-- 
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
[sig stoned - not available]
_wwwwooooowwwwaaaaaa so many colors_