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

List:       kmail-devel
Subject:    Re: [PATCH] UI abstraction proposal (partially only)=?iso-8859-1?q?
From:       Marc Mutz <mutz () kde ! org>
Date:       2003-06-10 19:37:59
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 03 June 2003 12:53, Zack Rusin wrote:
<snip>
> Personally I
> like the way Outlook does it - meaning that the gui asks the core for
> some specific info and the core just sends the data. So for me DCOP
> communication.
<snip>

Sorry for disturbing the party, but did I miss something? Who had this 
glorious idea to make a "KMail server"?

If it's all about the old dream of a command-line KMail, then my take on 
this is that the non-GUI code needs to go into a separate lib and KDE 
and ncurses frontends linking to that. IIRC, DCOP needs an X server and 
I don't think you want that dependency for a mutt-like clone.

As to concurrency: The better way IMO would be to make KMail reasonably 
robust against multiple instances acting on it's data (maildir should 
make this relatively painless) instead of cranking up a proprietary 
client/server protocol. That would automatically solve the procmail 
problem, too. That doesn't mean to go out of one's way to make it fool 
proof. It just needs to function well in the "keep running at work, but 
allow access at home, too" case. If you need full concurrent access, 
use an IMAP server.

I don't see why DCOP needs to be involved at all. There's no reason for 
using it for UI<->code coupling. This is just a fruitless excercise in 
distributed system programming. Just think about all the error handling 
necessary to prevent a dcop shell command from interfering with a UI 
session. You'll end up sanitizing every little parameter to every 
little method call. And since you won't catch all cases anyway, you'll 
end up with all sorts of problems and prossibly even security bugs.

I prefer in-process method invokation over distributed systems wherever 
the latter is not strictly necessary. Don't use DCOP just because 
you've just had a read through your new CORBA book and it sounded cool!

Please come up with a use case that requires DCOP/RPC and cannot be 
handled with simple library use!

I mean, we use khtml and kabc as libs/parts, and not as server 
processes, or do we?

Marc

-- 
We notice things that don't work. We don't notice things that do.
We notice computers, we don't notice pennies.
We notice e-book readers, we don't notice books.
                                          -- Douglas Adams

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