[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 11:54:14
[Download RAW message or body]

Hi,

On Don, 09 Dez 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.

Very well observed! I talked to Matthias about that already since he is one of
DCOPs daddy. I was just in the same Pizza Restaurant when it was born :-)

He suggested to implement the "activation of service" inside of kded.

So I would suggest an approach like this (and after 21.12 I can even implement
that):

ATTENTION: Big brainstorming session ....

kded gets a tiny DCOP interface that allows asking for a service.
kded can get the best service for a certain servicetype already
(See my previous mail and Simons mails on the topic).

Then kded must start the service and watch for its pid. If the app crashes
before it send its DCOPRef we return 0 to the calling client.

kded starts the new process like this:

app_to_launch_name -dcopref=magic_words

Once it registered itself at DCOP, kded is informed by DCOP (I think DCOP
can already inform about registered clients, or ? ).
kded does now have the DCOPRef and returns it to the calling client.

Of course you guys noticed where the problem is here:

kded needs to make a deffered response! That means:

a) It receives the call of the client
b) it starts the process is there is anything that matches the request
c) it returns to its event loop
d) dcop calls back or the started process died
e) kded sends deferred respone to the client.

Why like that ?

Becuase it is practical to block the client unil the requested service runs.
CORBA does it like this, too.

On the other hand konqui may not like to be blocked until a requested service
is there since it is sooooo async. So perhaps kded should feature two ways
of activating a service:

1) sync as outlined above
2) async.

Async: It is FORBIDDEN that kded calls back the client since that could lock
kded if the client is locked! (or?)
Before you say "no": You must be 100% shure here.
BTW: Is not it dangerous at all if kded accepts DCOP calls. Is there
an inherent danger of locks ?

However, async has to work like this:

a) client calls kded via dcop
b) kded searches the matching service and starts it with -dcopref=xyz
c) kded returns the DCOPRef "xyz"

Now the client must wait for DCOP to say: "xyz registed itself now".
-> kded can not be blocked by a bad client.

Problem: What if the started app crashes before it can register itself at DCOP ?
kded could transfer the pid, too, so the client has to watch for the pid, too.
But that would be much of a hack and would break the network transparency.
We could use a reasonable timeout here ....
Hmmmm .....

Got a tricky idea for async:

a) b) c) see above
d) kded still watches for the pid and wether the app registered itself.
    So it is like in the sync case, buttthhhh: If the app crashes before it
    was registered then kded calls dcop, telling that "xyz" has unregistered.
    DCOP will ignore the fact that it was never registered and sends out the
    message about it.
e) The client sees "xyz" unregistered but did not "register", so it crashed.

Another point is: What happens if the service requested is already running ?
a) kded asks DCOP for a running instance before it starts a new process
b) Returns the DCOPRef

Lets sum up the two protocols:

sync
----
a) kded receives the call of the client
b) It searches the matching service
c) Asks DCOP wether such service is registered -> return DCOPRef
d) it starts the process with "-dcopref=xyz"
e) it returns to its event loop
f) dcop calls back that the client registered or the started process died
g) kded sends deferred respone to the client. It returns the DCOPRef

Client side:
a) Call kded
b) We receiver a valid DCOPRef or 0 if the app crashes or service was
    not available.

async
----
a) kded receives the call of the client
b) It searches the matching service
c) Asks DCOP wether such service is registered -> return DCOPRef
d) it starts the process with "-dcopref=xyz"
e) it returns to its event loop
!!! f) dcop calls back that the client registered then we forget about it
!!! g) the process with the pid died -> kded calls unregister( "xyz" ) on DCOP

Client side:
a) Call kded via DCOP -> returns "xyz"
b) Returns immediately and goes in event loop
c) DCOP calls that "xyz" is registered -> done
d) DCOP calls that "xyz" unregistered but we did not see a register before
   -> Our app crashed.

Bot things need extensions to DCOP:
sync) deferred responses
async) unregister even if it was not registered.

Unfortunately activating services is no easy job. Ask the MICO guys ?
I heared them "scream" several times in front of their terminals when hacking
on that :-)

Bye
Torben

> ----------------
> 
> 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.
> 
> Just some thoughts.
> 
> Cheers,
> Waldo
> --
> Repeat after me: We are reimplementing CORBA

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