From kmail-devel Thu Jul 24 14:15:11 2003 From: Marc Mutz Date: Thu, 24 Jul 2003 14:15:11 +0000 To: kmail-devel Subject: Re: CIA proposal (was: ClientInterface) X-MARC-Message: https://marc.info/?l=kmail-devel&m=105905638406200 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============64126559225843427==" --===============64126559225843427== Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_vn+H/y+U7SawXP4"; charset=iso-8859-1 Content-transfer-encoding: 7BIT --Boundary-02=_vn+H/y+U7SawXP4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Don! I'm in the process of going home, so I'll address some points on=20 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=20 instance of KMail to close the folder or have a user click on the new=20 message will move the mails from new/ to cur/, updating the index along=20 the way. Of course, MUAs wishing to modify ~/Mail need to conform to CIA/4, but=20 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.=20 If a MUA dies while adding a message to the maildir, it will stay=20 incomplete in tmp/ until cleaned up. tmp/ is not monitored, so nobody=20 cares. If a MUA dies moving a message from tmp/ to new/ or cur/, either the=20 move happens completely or not at all. In the first case, another KMail=20 instance can try to add the message after waiting a certain amount of=20 time for the index to be updated. If the update doesn't arrive, the=20 addition is performed as if it was delivered. For this to work, the=20 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=20 any difference. Once a lib is split off of KMail for other apps to use,=20 I don't think most other apps will have a great need for the=20 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=20 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=20 config dialogs of two KMail's open at the same time, then he shouldn't=20 complain if the second-to-be-closed one overwrites the settings of the=20 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=20 checking mail will else break. Marc =2D-=20 Nie wird so viel gelogen wie vor der Wahl, w=E4hrend des Kriegs und nach der Jagd -- Otto von Bismarck --Boundary-02=_vn+H/y+U7SawXP4 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/H+nv3oWD+L2/6DgRAoKCAJ0YWpDwI0qEtoRnCsO0jG0KGT+WfwCgmuna Dx4IVSrX72WIUtEIcpFUoFk= =EBFv -----END PGP SIGNATURE----- --Boundary-02=_vn+H/y+U7SawXP4-- --===============64126559225843427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KMail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail --===============64126559225843427==--