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

List:       kde-core-devel
Subject:    Re: Future of DCOP
From:       Simon Hausmann <sh () caldera ! de>
Date:       2001-03-26 13:40:27
[Download RAW message or body]

On Mon, Mar 26, 2001 at 03:26:11PM +0200, Matthias Ettrich wrote:
> On Monday 26 March 2001 15:02, Simon Hausmann wrote:
> > On Mon, Mar 26, 2001 at 01:50:41PM +0200, Matthias Ettrich wrote:
> > > I've done some thinking about DCOP recently, under the lights of the
> > > ongoing problems with libICE on platforms other than Linux and the fact
> > > that it's unmaintained.
> > >
> > > Thinking about alternatives, there are really just two options, ORBit and
> > > MCOP.
> > >
> > > 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.
> > >
> > > DCOP is a nifty ipc solution based on standard X11 and libICE is
> > > definitely fixable.  But I really care more about semantics and ease of
> > > use than the binary format on the network. Replacing libICE with ORBit
> > > should be straight forward - almost. The only technical problem I see
> > > right now is for the DCOPServer to safely detect when a client goes down.
> > > I hope this is solvable, if not by adding something to ORBit. I haven't
> > > checked this yet.
> >
> > A simple mind-game (germany saying, doesn't translate very well into
> > english) : Would for our stuff (DCOP, XSMP) a simplistic GIOP
> > implementation based on Qt container types and QSocket and friends be
> > sufficient?
> >
> > (assuming we don't need the latest CORBA::DynAny, ORBit-IDL, etc. features
> > for our stuff)
> >
> > Of course we don't have such a thing at this point and ORBit is here and
> > now and probably a seriously feasible solution. But _if_ GIOP would be
> > sufficient....I would kind of like the idea... would be very interesting to
> > hack something like that.. :)
> 
> There's more to it than GIOP.  QServerSocket would help quite a bit, but not 
> with everything. You end up with at least the size of ICE or the MCOP core 
> (that is something between 7000 and 14000 lines of code). Do you really want 
> to maintain that and port it to various UNIX-like platforms?

I'd be less worried about portability (what would we do special?) . But 
maintaince is indeed a very strong argument.

Ok, convinced it's not the way to go :)

But if I understand your other mail correctly, then we do also want to access
real CORBA interfaces? So we would need an IDL compiler? (orbit-idl generates
C stubs and skeletons, and I guess we learned our lesson from mico-idl ;-)

But of course it's all a matter of how much you integrate and use it.
(if it's just for one or two common interfaces (say DCOP and maybe some common
XSMP interface) then the stubs and skels could probably be hacked by hand 
(using the ORBit DII/DSI))

Technically speaking of ORBit: It runs on the glib main loop, right? So
we would need to either merge it or look if ORBit allows an activation
scheme like ICE: We put up a QSocketNotifier and call a special
orbit_process_messages() method upon activation.

Hmmmm

Bye,
 Simon

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