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

List:       kde-pim
Subject:    Re: [Kde-pim] Re: ClientInterface (was Re: Fwd: [PATCH] kernel / UI
From:       Don Sanders <sanders () kde ! org>
Date:       2003-07-24 5:46:56
[Download RAW message or body]

On Tuesday 22 July 2003 00:07, Martin Konold wrote:
> Am Sonntag, 20. Juli 2003 13:36 schrieb don@sanders.org:
>
> Hi Don,
>
> > But that's read only mmap'd memory not normal r/w malloc'd
> > memory. When real memory is low then that ro mmap'd memory
> > doesn't have to be written back to disk like normal r/w malloc'd
> > memory, instead it can just be discarded/reused. Hence that
> > mmaped memory is like free'd memory and I don't think it makes
> > sense to count it as memory used by KMail anymore than it makes
> > sense to count free'd memory. This is a subtle but important
> > point.
>
> I fully agree with regards how you consider mmap'd memory. In
> general mmap is extremly efficient on Linux.

Excellent.

> > I'm concerned with modification of a folder that is opened by
> > multiple clients. Consider two clients with the same folder open,
> > and outstanding deletes pending for that folder in both clients.
> > Then when one client writes the index the other client will now
> > have an out of date version of the index for that folder. So all
> > the KMMsgBase objects will have invalid offsets into the index of
> > their parent KMFolder. That's a problem.
>
> Having two indepent clients work concurrently on the very same
> folder is impossible to solve in a reliable and consistent way
> without very much effort to avoid race conditions and message
> duplication.
>
> e.g. think about two MUAs accessing the same folder. MUA 1 is
> deleting and expunging a message while MUA 2 is editing the same
> message....

Maybe we are talking at different levels of thought. I hope you can 
bear with me if I step back and get some perspective on things for a 
few paragraphs.

The history of this discussion is one based on an attempt to solve 
some pretty specific problems.

Here's an example of this type of problem, in KAddressBook there's a 
Mail icon that can be used to open a composer and send a message to 
the currently selected addressees. That composer widget currently 
_isn't_ part of the KAddressBook process space. This is a bad thing. 
Ideally I want (at least the option) to embed KMail widgets in other 
apps.

You might agree that in the composer case a KMail client/server split 
makes some sense. The composer doesn't talk to the rest of the KMail 
that much. When it starts up it needs to get a list of identities and 
mail transports and default text for the from, reply-to, to, cc, bcc, 
subject and body fields. When the user is finished composing the 
message it needs to talk to the rest of KMail to say whether to queue 
or send the message and whether to encrypt the message or not. (Okay 
we also need to send a list of attachments too, small detail)

So we could create some DCOP methods in KMail just to support what the 
composer needs. Then split the composer code into it's own lib. KMail 
would link to this lib but so could other apps like KAddressBook. In 
the KAddressBook case the composer would appear in the KAddressBook 
space like any other KAddressBook widget.

Maybe something similar could be done for the other GUI parts of 
KMail. If I can embed KMail widgets in other apps then we can also do 
new things such as in KAdressBook select an addressee and click a 
button to show a list of headers of all messages from/to that 
addressee.

So that's the direction the server/client split is coming from. Anyway 
even if we don't go through with the whole idea, design wise it seems 
to be a good idea to separate the GUI/backend code anyway, so we are 
working on that. Rather than adding a lot of code we're breaking 
KMail up into loosely coupled components.

OTOH I think that adding code so that multiple KMail clients 
(processes) can directly access the same folder files on disk is 
probably "impossible to solve in a reliable and consistent way 
without very much effort to avoid race conditions and message 
duplication."

> Adding all this code trying to avoid these problems will lead to a
> major slowdown and an increase in memory usage of the common case
> (only a single MUA)

I agree that this is a very real danger. For this reason we've decided 
to move forward only with the GUI/backend code separation and 
postpone the introduction of additional private DCOP interfaces at 
this time.

Having said that the componentization approach is not without its 
additional benefits, if the KMail composer will be running in a 
different process it won't freeze while the KMail backend checks for 
mail, filters them and syncs them to disk. (See also
Bug:41514, KMail freezes the UI when checking for new mail, 299 votes)

(Same thing with scrolling the current message in the message reader 
widget)

> If concurrent access is required (like dIMAP is capable of doing)
> then use the dIMAP server approach. This has the additional
> advantage that existing clients dont have to be modified.

This is were I run into a mental disconnect. I'm not sure the 'dIMAP 
approach' can be used to solve the problems given in the KAddressBook 
examples above. dIMAP isn't going to help me show a KMail composer in 
KAddressBook process space is it?


Now let's step back a bit and look at things from a completely 
different angle. If KMail is componentized into backend and GUI then 
we can consider alternative implementations of the backend. The 
backend being the code that collects, sends, stores, retrieves, 
parses and assembles mails. (Retrieval covering searching, 
parsing/assembling covering decryption/encryption).

In this case I want to keep my options open. Maybe I'd like to 
componentize the backend and use mysql for storing/retrieving mail. 
This means I can use SQL to examine my mail. 

Or maybe I'd like to try something different. Maybe I'd like to 
install an IMAP server on my desktop, replace the KMail backend with 
a thin wrapper for the IMAP server, even going so far as to replace 
KMail's searching/filtering implementation (and anything else 
possible) with a wrapper around the IMAP functionality.

Hence in essence reducing KMail to being an online only GUI interface 
connecting to the local IMAP server thorough a wrapper process. Oh, 
and a client lib that provides an interface for other KDE apps to 
easily collect, send, store, retrieve (include search/track), parse 
and assembles mails.

If the IMAP server can do all the work no need to reinvent the wheel. 
And this approach would have a nice unixish peer-to-peer network of 
servers approach.

Anyway I would like to keep my options open.

Don.
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]