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) .

> 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)