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

List:       kmail-devel
Subject:    Re: [Kde-pim] Re: ClientInterface (was Re: Fwd: [PATCH] kernel / UI
From:       Don Sanders <sanders () kde ! org>
Date:       2003-07-19 7:23:27
[Download RAW message or body]

On Saturday 19 July 2003 07:51, Ingo Klöcker wrote:
> On Tuesday 15 July 2003 22:02, Andreas Gungl wrote:
> > I recommend to think over the targets to be worked for before any
> > further technical discussion continues. Is it to have different
> > UIs?
>
> No. At least not in the foreseeable future. There are already very
> capable text MUAs. IMO it doesn't make sense to even think about
> writing a text KMail client.
>
> > Is it to allow many other applications (perhaps still unknown
> > today) to interact with KMail's core?
>
> Definitely. The most important apps here are the KO and KAB parts
> in Kontact. If Kontact is used as Kolab client then currently the
> KM part has to run to allow KO and KAB to access the data which is
> stored on the IMAP server (which is part of Kolab).
>
> > Is it "only" a cleanup to separate core and UI code in the
> > current codebase?
>
> No. It's definitely more than a cleanup (see above).
>
> I'd like to see the following (in decreasing priority):
> a) We separate the backend in a (lightweight) library which will be
> used by the KMail GUI and also by KO and KAB.
> b) We finally make KMail work with other applications (including
> several KMails) that access ~/Mail. So we need to add proper folder
> locking and we need to watch the folders for changes.
> c) We kpartify the Composer and the ReaderWin so that they can be
> used inside other applications.

And you think that it makes sense to create this library without a
helper process?

You might like to consider why NFS and databases like mysql and
postgres use a helper process. And why a library that provides access
to messages in folders is similiar to a database that provides access
to records in tables or NFS that provides access to files in
directories.

In order to efficiently retrieve and store information databases
normally use a data structure known as a btree, a btree in some sense
indexes the information in the database, a bit like KMail index
files. It doesn't make sense for every database client to keep it's
own representation of the btree in memory, due to complexity of
keeping these representations in sync (database replication problem)
and the memory cost of having each client keep a copy of the
representation.

Likewise it doesn't make sense for every KMail client to keep a copy 
of KMFolderMgr and all the KMFolders in memory and burden KMail with 
further logic to keep these multiple copies in sync.

(Having said that peer to peer network technologies successfully
address these problems, but I think they are best reserved for the 
case where the peers are running on different machines).

If you come to the conclusion that a helper process is necessary then
you might like to consider whether the kernel part of KMail is a good
candidate to fulfill that role.

> I don't think that a complete separation of KMail into a server
> daemon and a client is a good idea. Some reasons:
> - Communication via DCOP causes much overhead because every little
> piece of data has to be put into a stream and has then to be read
> again from the stream. With a) this isn't necessary.

DCOP being simple is a good candidate to try first. But if DCOP proves 
too inefficient, KMail could be optimized or another IPC mechanism 
can be considered, and I believe IPC is needed.

> - We would have to add a whole lot of error handling code for each
> DCOP communication. Again with a) this isn't necessary.

It's no more/less necessary to add error handling for a DCOP
interface than for a library interface. Because if DCOP calls can fail 
then so can the library calls (due to failed file locking if nothing 
else).

> - We would have to add scheduling code to the server to make it
> work with concurrent clients. With a) and b) this isn't necessary.

With DCOP you get this for free, DCOP would be a pretty useless IPC 
mechanism if it didn't queue calls.

> - DCOP can only be used to exchange messages on the local machine.
> So if the user wants to run multiple KMails on different machines
> accessing the same ~/Mail directory (e. g. via NFS) the
> server/client separation doesn't help at all. b) solves this
> problem.

X11 natively supports displaying applications on different machines 
from that which they are being run on. No need to reinvent the wheel 
here.

> BTW, a simple solution for the callback stuff is the usage of
> signals and slots. I don't think it's necessary to add C-style
> callback functions just to be able to get some error messages from
> the kernel on the screen.

I'm not advocating C-style callbacks, I'm advocating partitioning
KMail into a server and client code spaces. And I'm trying to avoid
committing to DCOP at this stage, so as in my thinking (humor me) the
client and server should be able to run in different processes
signals and slots aren't sufficient.

Don.
_______________________________________________
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]