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

List:       kde-devel
Subject:    Re: network communication using DCOP
From:       Raphael Langerhorst <raphael-langerhorst () gmx ! at>
Date:       2004-03-20 13:59:21
Message-ID: 200403201459.21106.raphael-langerhorst () gmx ! at
[Download RAW message or body]

What I forgot... "do we even want such an addition to DCOP?"

* <insert your opinion here>


My thoughts are:

I'm working on a distributed application, currently built on Qt only. But 
seeing all those benefits from a KDE library (and dcop as a candidate for 
IPC) I'm also thinking of extending our base to KDE as well (at least DCOP if 
I find it usable). The application will consist of many many independent 
processes that do "something". And thus communication between these processes 
should be as seamlessly and fast as possible. Also a considerable amount of 
data *might* pass through this communication mechanism. And after all the 
application should be able to work distributed across a network, preferably 
the internet itself (we still have to see if data throughput requirements are 
ok for the internet).

So we need a well designed and easy to use IPC system - DCOP, as far as I know 
it yet, is quite good in this respect except that it lacks inter host 
communication.

I *think* currently a desktop environment is located on one host in most 
cases, but in years to come you probably have a laptop with you and a PC (or 
whatever) at home/work and want to seamlessly interoperate with all 
appications running. If then DCOP already features such required 
communication mechanisms then it would be good (and faster to provide such a 
modell).

Regards,
Raphael


On Saturday 20 March 2004 13:59, Raphael Langerhorst wrote:
> On Tuesday 16 March 2004 21:07, Raphael Langerhorst wrote:
> > On Monday 15 March 2004 20:18, Christian Loose wrote:
> > > You might want to take a look at kdenonbeta/saape instead which is a
> > > SOAP<->DCOP bridge. Unfortunately there wasn't much development after
> > > the initial check-in.
> >
> > I'll have a look at it,
>
> hmmm, just had a look. There is not much documentation there... and I can't
> even compile because todays kdenonbeta fails to configure (didn't spend any
> time trying to fix it). Maybe saape is even useful, but another thought
> just came up:
> what about adding network support do DCOP directly, I mean something like a
> "DCOP server <-> network (that is, own simple - and fast - protocol) <->
> DCOP server" bridge.
>
> Currently I'm thinking about two possibilities to implement that:
>
> 1) either enable dcop clients to give an additional parameter to send
> commands that would represent the remote server (either IP-adress or
> hostname), so the message gets transfered to the remote host first and the
> dcop server there handles the command.
>
> 2) make the dcopserver network aware (that is, listen on a specific port).
> Additionally allow clients to connect to a remote dcop server (an extra
> optional parameter to attach() or sth).
>
>
> Both of these probably need some modifications in the ICE library. What I
> would propose here is to add an additional library with a similar interface
> to ICE. The dcopserver than uses ICE connections for local messages and the
> other library for remote communication.
>
>
> If some explainations given here are "clumsy" and are not dcop-like then
> it's because I haven't read much of the source code of dcop yet but am just
> about to do that. So my descriptions should get better the more I know
> about the internals of dcop.
>
>
> Maybe an additional word about standards like XML-RPC or SOAP... sure it's
> nice to have such bridges - and I don't think what I propose interferes
> with that. But they are held very "general" which would cause additional
> protocol overhead that could be avoided with a clean and simple network
> protocol between the dcop servers (for proposal 1) respectively between
> dcop client and remote dcop server (for proposal 2).
>
>
> What do you think about that? And what option do you favor?
>
> Raphael
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]