[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: CIA proposal (was: ClientInterface)
From:       Marc Mutz <mutz () kde ! org>
Date:       2003-07-24 14:15:11
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi Don!

I'm in the process of going home, so I'll address some points on 
shortly. I apologize.

On Wednesday 23 July 2003 06:58, Don Sanders wrote:
> I do wonder if multiple processes ro mmap the same file whether the
> memory used to back the mmap is shared by all those processes.

It is (if you use MAP_SHARED).

> My concerns:
>
> 1) This doesn't actually address the issue of external mail clients
> modifying ~/Mail does it? I mean not even for MailDir as this
> approach requires KMail to be running to detect changes in ~/Mail.

New mail is delivered into the new/ subdir for maildir. The first 
instance of KMail to close the folder or have a user click on the new 
message will move the mails from new/ to cur/, updating the index along 
the way.

Of course, MUAs wishing to modify ~/Mail need to conform to CIA/4, but 
maildir-compliant MDAs work without modifications.

> 2) I'm concerned that this approach could be fragile. A client might
> die after deleting/inserting a Maildir message but before updating
> the index, or vice versa. Maybe this can be handled robustly so this
> is just a concern not a concrete criticism. But clearly this method
> does rely on mbox style locking rather than maildir style elimination
> of the need for locking.

Locking is only necessary for the index files, not the mails themselves. 
If a MUA dies while adding a message to the maildir, it will stay 
incomplete in tmp/ until cleaned up. tmp/ is not monitored, so nobody 
cares.

If a MUA dies moving a message from tmp/ to new/ or cur/, either the 
move happens completely or not at all. In the first case, another KMail 
instance can try to add the message after waiting a certain amount of 
time for the index to be updated. If the update doesn't arrive, the 
addition is performed as if it was delivered. For this to work, the 
sernum has to be added as a x-KMail header to the mail.

> 3) If this approach works then it does address the criticism of
> having multiple clients modify index files but there's still the
> memory costs associated with this approach. Each client will need
> there own kmmsgdict, IIRC each entry in the kmmsgdict maps a
> sernum -> (folder , index ) which is an int -> (int, int) mapping or
> 12 bytes. I have >500K messages currently, so that's >6MB per client
> instance.

You typically won't run that many KMail instances that these few MB make 
any difference. Once a lib is split off of KMail for other apps to use, 
I don't think most other apps will have a great need for the 
dictionary.

> And then there's the full text index. A full text index is by it's
> nature a large object as it's space/time tradeoff. For me it's >
> 24MB.

See above. Can be loaded on demand and most clients won't want to use it 
anyway.

> Besides folder files there are also other files than need to be
> handled. The config file is a problem if it is desirable to have each
> client keep their config dialogs and general configuration info in
> sync.

I'm cool with having that break. If a user is dumb enough to keep the 
config dialogs of two KMail's open at the same time, then he shouldn't 
complain if the second-to-be-closed one overwrites the settings of the 
first-to-be-closed one. I don't see a need to make that work.

> Another set of files is the list of mails that are kept on the server
> for each account.

These are different. Locking is the std answer I'd give here ;-)
You have to have locking for accounts anyway. Two instances concurrently 
checking mail will else break.

Marc

-- 
Nie wird so viel gelogen wie vor der Wahl, während des Kriegs und nach
der Jagd                                          -- Otto von Bismarck





[Attachment #5 (application/pgp-signature)]

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail


[prev in list] [next in list] [prev in thread] [next in thread]