[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:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2003-07-18 21:51:26
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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.

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

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.

Regards,
Ingo


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