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

List:       kde-core-devel
Subject:    Re: dcop interfaces, standard ?
From:       Torben Weis <weis () stud ! uni-frankfurt ! de>
Date:       1999-12-09 13:10:29
[Download RAW message or body]

Hi,

On Don, 09 Dez 1999, Simon Hausmann wrote:
> On Thu, 9 Dec 1999, Waldo Bastian wrote:
> 
> > 
> > > As you can see there are problems overall. Lets jump out of the window :-)
> > > It depends on where you assume the smallest trouble for your program.
> > > For KOffice, Konqui and others we had the smallest trouble when doing 
> > > embedding with shared libs and scripting&stuff with DCOP.
> > 
> > The problem here is that Bernd seems to be looking for the "scripting&stuff" 
> > part and many other people only think about "embedding with shared libs".
> > 
> > We need both and support for "scripting&stuff" is lacking at the moment.
> > As noted earlier:
> > 
> > * we need a working and reliable trader for it.
> > * we need some workable default interface descriptions.
> > 
> > Trader requirements
> > --------------
> > 
> > Applications must be able to request for a service. The trader must response 
> > with some sort of pointer to the required service or report failure.
> > 
> > The trader must make sure that the service is indeed ready to accept requests
> > before returning to the requesting application!
> >
> > Just launching the application is not enough because then there will be a 
> > time-frame in which the application is running but in which requests to it will 
> > be lost because the application has not yet registered itself with DCOP.
> 
> (just a sidenote)
> 
> I once discussed this with Matthias Ettrich on IRC and he agreed with
> adding support for a commandline option like "-dcopnotify" to kapp, which
> takes an address as argument.
> 
> So that calling
> someapp -dcopnofity myapp::someobj::anotherfunc
> will make someapp issue a DCOP call to the specified address as soon as
> the application is registered with the dcopserver (as a solution to get
> rid of the time-frame problem) .

See my previous mail. I think that is not enough, because
a) it as async, but often sync is smarter
b) No chance to detect that the app crashed before it could register.

Bye
Torben
 
> > Interface requirements
> > ----------------
> > 
> > Typically we will have running UNIX processes with multiple mainwindows. If 
> > such a process implements a DCOP interface we must take care that DCOP commands 
> > do not interfere unexpectedly with existing mainwindows. 
> > 
> > Example: KEdit has two main-windows open. When an apllication requests KEdit 
> > via DCOP to open a new document and then requests to print this document we 
> > must make sure that the right document gets printed and not the one in another 
> > main-window. Even if, at that same time, another application request KEdit via 
> > DCOP to do something similair. Or if the user closes a window.
> > 
> > Typically we need to pass around "handles" and application implementing DCOP 
> > interfaces must make sure to test their validity.
> 
> As "handle" Torben already implemented DCOPRef, so we could make use of
> that :)
> 
> Ciao,
>  Simon (totally agreeing with all points Waldo mentioned)

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