Re: RFC mailbox interface
- From: "M . Thielker" <balsa t-data com>
- To: balsa-list gnome org
- Subject: Re: RFC mailbox interface
- Date: Sun, 25 Nov 2001 20:30:33 +0100
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
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
> 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
> 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.
] [Thread Prev