[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: dcop interfaces, standard ?
From: Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date: 1999-12-09 11:03:39
[Download RAW message or body]
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)
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic