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

List:       kde-core-devel
Subject:    Re: dcop interfaces, standard ?
From:       Waldo Bastian <bastian () suse ! de>
Date:       1999-12-09 14:15:11
[Download RAW message or body]

On Thu, 09 Dec 1999, Torben Weis wrote:

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

Yes. That would be nice.

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

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

Yes. I would like to use this behaviour in the cookiejar as well.
(Since I would like to block a cookie-lookup if I the cookiejar is asking the 
user what to do with a just received cookie that would match the lookup.)
((We couldn't get this right in KFM))


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

I know :-)
 
> 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 ?

Well.. we have "call" and "send". In async mode we should only use "sends".
I don't think they block. They just might fail.

> Lets sum up the two protocols:
[Skip]

The behaviour of sync and async should be the same. It is just that a synced 
call blocks within DCOPClient->call() and the async call calls 
DCOPClient->send() and hopes that it will ever get a DCOP send event back.

Within kded there isn't much difference either. For a synced request there 
needs to be a mechanism to defer the answer to a DCOP call, since we don't want
to block kded while it is starting a service. (Risk of deadlock)
An async request doesn't need that it can just handle the request which it got 
"sended" to it and when it knows the answer it can "send" the answer back.

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

On the topic of "handles" I mentioned before. Instead of a handle we could use 
a DCOP client instead:

Example: Applications wants to open a file in an editor and print the file.

app -> kded: "Give me an application that can handle file with mimetype XYZ and 
that implements interface DEF"
kded -> app: "Here it is, I started it for you and it's DCOP name is 'kedit'."
app -> kedit: "Open the file file:/somefile/somewhere for me."
kedit->app: "Done. You can talk to my editor window called "kedit-file67" if 
you want to do anything else with it."
app->kedit-file67: "Would you be so kind to print yourself?"
kedit-file67->app: "Done."

If we can make sure that the ID "kedit-file67" isn't used for a while after its 
get destroyed we have solved most problems with handles. That's not too 
difficult: just use QString("kedit-file%1").arg(large_random_number).

Con: A drawback of this is that it doesn't scale very well, if your application 
wants to keep 1000 handles around it means that the dcopserver gets swamped 
with 1000 connections. (Solution: don't do that :-)

Pro: The DCOP stuff does does all the hairy stuff for you and it is already 
there :-)

Cheers,
Waldo

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