[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:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2003-06-11 11:35:28
[Download RAW message or body]

On Tuesday 10 June 2003 21:37, Marc Mutz wrote:
>
> 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.

DCOP in principle doesn't need an X server, although the implementation 
sometimes required that.

> 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!

I have to agree with Marc here. DCOP is nice for inter-process 
communication, but it has a couple of disadvantages over direct library 
interaction, e.g. that it is hard to debug, because the compiler can't 
check DCOP calls the usual way (have you ever tried to debug problems 
with DCOP signal connections?), data can only be passed by 
serializing/deserializing it or that it generates quite some overhead 
for each function call.

If KMail would internally use DCOP for all interaction between GUI and 
backend, this would probably make developing for KMail much harder, 
especially for new developers. I don't think that this would be a 
desirable situation.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
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]