--===============65073044793927703== Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_ksRI/AoyjBPSN/k"; charset=us-ascii Content-transfer-encoding: 7BIT --Boundary-02=_ksRI/AoyjBPSN/k Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 25 July 2003 08:30, Don Sanders wrote: > On Friday 25 July 2003 00:15, Marc Mutz wrote: > > Of course, MUAs wishing to modify ~/Mail need to conform to CIA/4, > > but maildir-compliant MDAs work without modifications. > > Ok, but what about the case of another (non-KMail) mail client moving > mail from new/ to cur/ while KMail is not running. KMail detects new mail has arrived after last exit (e.g. checking the=20 last-modified-date of new/ and cur/) and updates it's index after=20 obtaining the write lock. For maildir, the link between the file and=20 the index is the file's basename (without the status bits at the end),=20 which never changes, so incremental index updates are relatively cheap. However, the server approach has the same problem, hasn't it? > How will you set the timeout for the lock? Some operations in KMail > take a long time so perhaps there's a danger of mistakenly thinking > the lock is stale when really a KMail client is busy, right? If you re-read my earlier mails, then of course the complementary goal=20 is to make KMail non-blocking for all long operations. In additon, a=20 timeout triggers a message to the user, who will know if it's other=20 KMail is doing some long operation. You have the same thing with the client/server approach. Either you make=20 the server non-blocking or KMail clients need a way to distinguish the=20 case that the server died from the case that the server is serving a=20 blocking request. > Half a year ago I spent some time trying to delay the loading of the > dictionary to make startup of KMail faster. > > But personally I couldn't manage it. We use serial numbers quite a > lot now as they provide a safe way of keeping a reference to a > message, even at startup the dictionary is used (in KMReaderWin) when > the initial message is displayed. This is just a workaround for the fact that there's no ref counting for=20 either messages or folders. > It seems to me that any client that wants to display messages will > use the dict. I would have thought that this is a pretty common case, > would you not agree? Displaying messages (or parsing them to extract an iCal like KO'd do) is=20 prettry common, yes. But there's no need for sernums here. If KMail is=20 able to lose references to messages during the lifetime of an KMail=20 instance, then there's something wrong. In this case, it's missing=20 refcounting. > Unfortunately the case of the full text index seems to be an even > more difficult one. As in order to keep the full text index up to > date it must be running whenever mail is discovered, altered, copied, > or moved. Wouldn't this be a pretty typical kind of thing for clients > todo? You coul do lazy updates. Only update the index when it needs to be=20 there. No need for updating it unless the user performs a search or=20 opens a search folder. > I wonder if a client can't efficiently handle either of these cases > what useful task could a client do efficiently? There was life before the full text index. It probably was slower.=20 There's a speed/space tradeoff here and each clients need to decide=20 what's more important for them. > > > 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. > > Ok. But even if that was acceptable wouldn't there be a problem on > say session exit with all the clients updating the config file at > exit? Nope. The last session wins. > I mean say a new account was created in one client, couldn't that new > account be lost if another client closed after the client where the > new account was created? Nope. Writing the complete config file on exit is nonsense (even if=20 KMail currently does that). Of course, you write only the session=20 config and then it's "last session wins" again. It's simply not=20 necessary to make every conceivable thing possible with concurrent=20 access. Keep the perspective: As Ingo said, the typical scenario is to=20 have at most two or three full KMail instances running at the same=20 time, only one of which is interactive in the sense that the user does=20 something with it. Most stuff needs to be solved either way. For one thing, the client/ server approach is more convenient, for others it's CIA. The net result=20 as I see it is that CIA is both more performant (almost no socket=20 traffic), works (for the most part) over NFS and is easier to maintain=20 once the necessary changes have been made. It is also the way to go if=20 there's anything like a multithreaded KMail coming along in the distant=20 future. CIA has techniques that help also a normal KMail to reduce resource=20 usage. It doesn't add much in the way of complexity for single-instance=20 mode. IOW, it optimizes (also) the common case, not the rare one, as=20 the c/s approach does. CIA also covers the MDA-delivers-into-~/Mail case, which the server has=20 to solve, too, probably with the exact same techniques that CIA uses. So you can also say that the server needs CIA techniques in addition to=20 it's own complexity. So what's left is full client/server complexity=20 vs. the need to lock a few files. The "Composer freezes on new mail check" is _not_ an argument against=20 CIA or for the client/server approach. It's again the reasoning that I=20 ranted about earlier: Instead of fixing the problems, let's work around=20 them using a server. Not. Marc =2D-=20 We notice things that don't work. We don't notice things that do. We notice computers, we don't notice pennies. We notice e-book readers, we don't notice books. -- Douglas Adams --Boundary-02=_ksRI/AoyjBPSN/k Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/IRsk3oWD+L2/6DgRAj5vAKDkB7l6Dipjh6rlkOXIlSFAaD7A9QCbBpQ4 ksBzDL2zlxCKiZ4ZHLqn32g= =45aq -----END PGP SIGNATURE----- --Boundary-02=_ksRI/AoyjBPSN/k-- --===============65073044793927703== 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 --===============65073044793927703==--