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

List:       mico-devel
Subject:    MICO: ImplRepo question (Was: "Re: konqueror - multiple instances" on
From:       Steffen Hansen <stefh () mip ! sdu ! dk>
Date:       1999-07-19 10:48:36
[Download RAW message or body]

I send this mail to the MICO list with hope that someone with good
knowledge of MICO will give some input... Basically i have 2 questions for
the MICO experts:

How do i get a shared server to register with the BOA daemon when the
server isn't startet by the IMR? In KDE the eqiuvalent of the BOA daemon
has an IMR entry for the server, it just need to know that it was started
"by hand" and not by the IMR.

Is it possible for the BOA daemon to check if the server has crashed and
then restart it when a client bind to the server object?

Below follows the original discussion and my own experiences with the
CORBA stuff in KDE:

On Mon, 19 Jul 1999, Waldo Bastian wrote:

> Simon Hausmann wrote:
> > > can't kded detect that situation and unregister applications 
> > > that died automatically?
> 
> > Of course it can. That's what the Mediators for BOA/POA do, but 
> > it does only work if Konqueror got started by them, which is not
> > the case when the user started konqueror.
> 
> Can't konqy restart itself via the Mediators then?

I had a look at the object-adaptor/mediator stuff again. The MICO doc says
that servers with the Persistent activation mode will register with the
BOA daemon (in our case kded) if they are started with the 
"-OARemoteAddr <kded-addr>" option. The problem with Persistent servers
are that they will _not_ be activated to be mediator. So we really need
something that is between Shared and Persistent.

I played a bit with making konqy a Persistent server and starting it with
-OARemoteAddr, but it doesn't work with kded. I tinkered a bit the repoid
and tag (What is the #App in the repoid for?? I stripped it out and used
"App" as a tag, is that right?), but could only get this from kded:

creating reference for Konqueror with repoid IDL:Konqueror/Application:1.0
Incarnating .... 
Incarnating Konqueror with id IDL:Konqueror/Application:1.0 and tag App
binding with tag App and addr unix:/tmp/kded-11110
could not bind to server: Konqueror 

My test app looks up "FileManager" in the trader and activates the
service with KAtivator. I tossed some quick DII code together to actually
call a method on the resulting object, but all i get is an 

uncaught MICO exception: IDL:omg.org/CORBA/OBJ_ADAPTER:1.0 (0,
not-completed)

So it looks like the mediator or activator code is rather confused about
the whole thing. I noticed that konqueror never tells the BOA that it's
ready for action (by calling BOA::obj_is_ready() or BOA::impl_is_ready()).
Could that be the reason why kded fail to bind to the Konqy object?

And finally: What is KNaming really for? If KActivator::activateService(
sname) did

if( sname is running already and has mode Shared or Persistent) {
	ref = object ref. to server sname;
	if( ref points to something that works and didn't crash)	
		return( ref);
}
return( create_reference_with_id(sname)); //As it does now.

would we then need KNaming at all? I dont know how to implement the if's
though.

-- 
Steffen Hansen                            
email: stefh@mip.sdu.dk, stefh@imada.sdu.dk, hansen@kde.org 
URL:   http://www.mip.sdu.dk/~stefh       

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