On Wednesday 11 June 2003 21:35, Cornelius Schumacher wrote:
> 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.

I think not using DCOP is fine for most of KMail, for all the client 
code, but for the small amount of GUI code in the KMail kernel I 
think using a DCOP interface makes sense. 

We should do this anyway so that when other KDE apps use DCOP services 
KMail provides any GUI windows/widgets that are created are owned by 
the client app instead of the KMail process.

Don.
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail