On Monday 26 March 2001 14:33, Dirk Mueller wrote:
> On Mon, 26 Mär 2001, Matthias Ettrich wrote:
> > Given that MCOP is meant for multimedia and that we eventually will have
> > to or want to utilize ORBit anyway in the future for all kinds of desktop
> > cooperation (accessability, session management (XSMP over ORBit rather
> > than ICE), network directory services, ...), I'd like to evaluate porting
> > DCOP over to ORBit as underlying communication layer.
>
> what advantages has orbit on the technical side over ICE ? 

1. Maintained. 
2. Gives access to CORBA interfaces. 
3. Opens room for cooperation.

Regardless what kind of cooperation we are going to do with Gnome and/or 
other parties (accessibility, registry, components ...) you will always end 
up with the requirement for a common ipc solution.

> I mean, does it
> use a faster way of interprocess communication than sockets / pipes ? does

Not necessarily faster, but it uses a mechanism that is just as fast. Not 
that the CORBA interface required by DCOP is very small ( basically a send, a 
receive and a call method).

> it use less memory ? 

At least it doesn't seem to use much more memory.

> will the dcopserver process be obsolete then and be
> replaced by orbit ?

No, ORBit (just like any other CORBA ORB) does direct peer to peer 
connections. Think of it as a library like libICE, not as a process. The 
DCOPserver will still exist, but rather then talking ICE to its clients, it 
will talk IIOP via ORBit.

>
> Is orbit useable without having to use the CORBA marshalling ?

no, but we'll put DCOP marshalling on top of it. All DCOP needs is a stream 
of bytes, so there is no marshalling overhead, neither with GIOP nor with ICE.

>
> will it be possible to easily integrate the qt <-> CORBA marshalling for
> easy interopability with gnome apps ?

That's the long term goal. Once we have ORBit linked to all KDE applications, 
steps like that will be natural and easy. 

At the beginning it will be cost us slightly more resources, since we have to 
keep ICE around for XSMP. But as I indicated, this might change in the 
future. Nobody apart from GNOME and KDE supports XSMP anyway, so we could 
easily change the underlying protocol in cooperation.

>
> If none of the questions above can be answered with "yes" I don't see the
> point converting to orbit just for the single point of being
> buzzword-compliant. I'd rather fix libICE with cooperation of the X people
> then.

There are no more X people that feel responsible for libICE. Those who knew 
anything about it, retired a long time ago.

So from KDE's perspective we replace one unmaintained black box of C-code 
with a maintained black box of C-code,  and whenever somebody complains about 
DCOP errors we can blame the Gnomes ;-)

>
> For binary compatibility reasons we won't be able to do that before 3.0
> anyway :-/

Not necessarily, it's perfectly possible to do that in a binary compatible 
way. All you would have to do is to replace your libdcopclient.

Matthias