Re: RFC mailbox interface

["M . Thielker" <balsa t-data com>]

Hi,

On 2001.11.24 01:58 Carlos Morgado wrote:
> 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
> 
But it does. It does exist in more than one place, physically. The lib 
should only choose to load the message from the fastest source available, 
but it _will_ physically be in all the mailboxes it appears to be in. I 
never said I wanted to keep just one, central copy, I _do_ want to have the 
message stored in every folder it should be. That's a very basic 
requirement, as other programs, that are unaware of the machanics of the 
lib can also access and process the folders.

>> Opening the message from a remote folder, I would go ahead and load the 
>> local copy instead...
>> 
> that should be transparent to the user
> 
Yes, exactly. If there is a message in any open local folder that is known 
to be an identical copy of the remote message requested, the data from the 
local folder is simply substituted and a network transfer of the message 
avoided.

> 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
> 
True. That would change the fingerprint of the message and therefore 
disassociate the edited message from the original. It would become a 
separate message.

> 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.
> 
Well, layers are a nice thing, but also bear in mind that, in the not too 
distant future, the common Balsa user will know no more about his OS than 
the common M$ user does today. I firmly beliebe that Linux, or maybe 
something evolved from Linux, will eventually replace Windows on the 
desktop. If you make something too hard to use or to configure, people will 
not accept it. Having a mailer config file, a mail processor config file, a 
proxy config file, and so on, would just be too much.
I think that Balsa, for the tasks needed for that simple desktop user, 
should incorporate all needed functionality into itself. That is, mailbox 
opening and indexing, message rendering and printing, message composition, 
sending by SMTP and reception by POP3, and accessing IMAP servers.
Assuming that all this is to be rolled into Balsa, there is no need to 
separate rwo functions that can be written more efficiently when combined.

>> 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 :) --
Why not? Read benchmarking should work on anything. Collect stats over 
time, and adjust the values at runtime, continuously.

Melanie