[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-25 11:57:14
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 25 July 2003 08:30, Don Sanders wrote:
> On Friday 25 July 2003 00:15, Marc Mutz wrote:
<snip>
> > 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.
<snip>

KMail detects new mail has arrived after last exit (e.g. checking the 
last-modified-date of new/ and cur/) and updates it's index after 
obtaining the write lock. For maildir, the link between the file and 
the index is the file's basename (without the status bits at the end), 
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?
<snip>

If you re-read my earlier mails, then of course the complementary goal 
is to make KMail non-blocking for all long operations. In additon, a 
timeout triggers a message to the user, who will know if it's other 
KMail is doing some long operation.

You have the same thing with the client/server approach. Either you make 
the server non-blocking or KMail clients need a way to distinguish the 
case that the server died from the case that the server is serving a 
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 
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 
prettry common, yes. But there's no need for sernums here. If KMail is 
able to lose references to messages during the lifetime of an KMail 
instance, then there's something wrong. In this case, it's missing 
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 
there. No need for updating it unless the user performs a search or 
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. 
There's a speed/space tradeoff here and each clients need to decide 
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 
KMail currently does that). Of course, you write only the session 
config and then it's "last session wins" again. It's simply not 
necessary to make every conceivable thing possible with concurrent 
access. Keep the perspective: As Ingo said, the typical scenario is to 
have at most two or three full KMail instances running at the same 
time, only one of which is interactive in the sense that the user does 
something with it.

<snip pro-client/server stuff>

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 
as I see it is that CIA is both more performant (almost no socket 
traffic), works (for the most part) over NFS and is easier to maintain 
once the necessary changes have been made. It is also the way to go if 
there's anything like a multithreaded KMail coming along in the distant 
future.

CIA has techniques that help also a normal KMail to reduce resource 
usage. It doesn't add much in the way of complexity for single-instance 
mode. IOW, it optimizes (also) the common case, not the rare one, as 
the c/s approach does.

CIA also covers the MDA-delivers-into-~/Mail case, which the server has 
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 
it's own complexity. So what's left is full client/server complexity 
vs. the need to lock a few files.

The "Composer freezes on new mail check" is _not_ an argument against 
CIA or for the client/server approach. It's again the reasoning that I 
ranted about earlier: Instead of fixing the problems, let's work around 
them using a server. Not.

Marc

-- 
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

[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]