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