[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-21 4:20:57
[Download RAW message or body]

On Saturday 19 July 2003 21:31, Ingo Klöcker wrote:
> On Saturday 19 July 2003 09:23, Don Sanders wrote:
...
> > > 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.
>
> Yeah, let's use a proprietary IPC mechanism. Not. I thought you
> wanted to make it possible for other KDE applications to use the
> daemon. Then you will have to use DCOP unless you want to introduce
> another layer in terms of a library which hides this proprietary
> IPC from clients who want to access the daemon.

I would like to see the creation of a client library, I don't want 
random apps accessing the KMail client/server IPC interface.

> > > - 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).
>
> Wrong. We would have to add additional code to handle failed DCOP
> calls. With a library that's not necessary because if the library
> couldn't be loaded then the app didn't start in the first place.

Even if the library successfully loads, calls into the library could 
still fail, that's all I'm saying.

> > > - 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 doesn't really help if the server is performing an expensive
> operation for one client while another client only wants to get a
> message. In this case the server should (if possible) interrupt the
> expensive operation, give the other client the message and then
> continue the expensive operation.

Sure we have problems with time consuming operations blocking the UI. 
DCOP won't magically solve those problems.

> > > - 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.
>
> Yeah, let's go back to the good old times where all applications
> ran on a server and the local machines were mere terminals. Sorry,
> but people who have an NFS mounted home directory want to run KMail
> on the local machine.

I think with NFS there's a reliability/speed tradeoff involved. Most 
people seem to trade reliability for speed in which case I don't see 
how to reliably solve this problem with either the client/server or 
client only solution. Where 'this problem' is having multiple KMail 
clients (not running on the NFS server) efficiently and concurrently 
accessing mail on an NFS server.

You may believe that you can solve this problem using the client only 
solution, but in my opinion KMail can't currently reliably handle 
mail on NFS so I'd like to reserve my judgment on that matter.

> BTW, you didn't say anything about b) (i. e. stop KMail's
> dictatorship of ~/Mail).

I'm not currently concerned with the dictatorship of ~/Mail. I'm 
concerned with a separate problem, allowing multiples KMail clients 
to run simultaneously in separate processes on the same machine. I 
consider this problems separate.

I think I've addressed all criticisms of the server model. Please 
inform me if I missed any.

Ok, a further problem with the client only solution has occurred to 
me. To recap here is a summary of the outstanding criticisms:

Allowing other processes to modify KMail's index files while they are 
open will result in invalid KMMsgInfo objects that could corrupt the 
index files. I'll call this the invalid KMMsgInfo problem.

Two solutions have been suggested, I find neither acceptable.

The first suggestion was to have KMail make a private copy of any 
folders it has opened. I have global searches that open most of my 
folders. This would mean each client would need to copy about 2gigs 
of ~/Mail data. I don't think this acceptable.

The second suggestion was to have KMail lock index files only briefly. 
But this would means redesigning KMail so that index files are 
read/written whenever an action takes place. Theoretically feasible 
but basically requiring a rewrite of most of all the non-GUI KMail 
code, and resulting in slow performance when multiple clients 
interleave changes into an index file, requiring both clients to 
continually reparse the index file.

Which is the second problem the updating multiple clients problem.

If a server is used then there's a central point (the server) where 
changes are managed and at this point all clients can be informed of 
the changes. The client only solution would require each client to 
poll files for changes and possibly reparse the entire index file 
each time it is changed. Too expensive for my tastes.

The third problem is the duplicate serial number problem. This is 
solvable in the client model by using a shared file. But I do find 
this solution very ugly and would prefer to have a single server 
process give out numbers instead.

On to a new problem, a fourth problem, the lost messages problem.

Consider the case of the user opening a composer by replying to a 
message, moving that message into a different folder and then sending 
the reply. In this case the message has to be found and the status 
changed to replied. Currently we use the kmmsgdict to find the 
message.

With the server model we could continue to use the single kmmsgdict. 
But with the client only model there would be multiple kmmsgdicts and 
they would no longer be reliable. Because if the message was 
replied-to and moved by different clients then the replied-to client 
would not know what folder the message was moved into. In the client 
only model keeping the kmmsgdict up to date in all the clients would 
require polling the index files and reparsing them whenever they 
change. So the client only model would require reparsing all folders 
whenever they change. I consider this an unnecessary and 
unjustifiable expense.

The serial number problem I could overlook as there is a solution to 
it, albeit an ugly one. But until solutions to the other three 
problems are given I'll consider the client-only model fundamentally 
flawed.

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]