orbit-python-list

[Orbit-python-list] RootPOA

[Christian R. R. <ki...@as...>]

This is more of a Orbit question but I'll crosspost so Jason gets some
email :-)

AFAICS, Orbit-0.5.3 only implements RootPOA as a possible request to
resolve_initial_references. Is this true? Can I not access
the NameService object?

I've been quite confused about how exactly this would work. I understand I
can set an IOR for the name server in orbitrc, but how far down Orbit and
orbit-python this goes is unknown to me. Can I actually use this inside
orbit-python today?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] RootPOA

[Jason T. <ta...@li...>]

> This is more of a Orbit question but I'll crosspost so Jason gets some
> email :-)

Aww, gee, thanks for thinking of me. :)

First, a disclaimer: I haven't looked at this code in a while and I'm
awfully rusty.  I'm especially sticking my neck out when I talk about
ORBit internals, so pay more attention to say Elliot or Owen before me.
:)

> AFAICS, Orbit-0.5.3 only implements RootPOA as a possible request to
> resolve_initial_references. Is this true? Can I not access
> the NameService object?

I was reasonably sure you couldn't pass NameService to
resolve_initial_references with ORBit, and a quick perusal of ORBit's
source shows this to be the case.  The name service object only seems to
be set on calling set_initial_references, which doesn't help much when
you don't have a reference to the object to begin with.

Fetching a reference to GNOME's name service, at least, is done with
Gnorba's gnome_name_service_get().  I don't think there is some elegant
way with strictly ORBit (please correct me if I'm wrong).  For now it's
a matter of finding the IOR from the naming service and calling
string_to_object on it.

> I've been quite confused about how exactly this would work. I understand I
> can set an IOR for the name server in orbitrc, but how far down Orbit and
> orbit-python this goes is unknown to me. Can I actually use this inside
> orbit-python today?

In theory if you import the CosNaming module (in non-cvs versions you do
this with load_idl, with the CVS version just import CosNaming and it
does everything magically) and pass the IOR to string_to_object, you
should have a NamingContext object to play with.  In practice, there
seems to be some sort of bug with ORBit-Python that I still need to
track down and this will fail.

Jason.

Re: [Orbit-python-list] RootPOA

[Christian R. R. <ki...@as...>]

On Wed, 29 Nov 2000, Jason Tackaberry wrote:

> I was reasonably sure you couldn't pass NameService to
> resolve_initial_references with ORBit, and a quick perusal of ORBit's
> source shows this to be the case.  The name service object only seems to
> be set on calling set_initial_references, which doesn't help much when
> you don't have a reference to the object to begin with.

Apparently you can set an IOR for the NameService in your orbitrc, but I
have yet to see this work. This code fragment in 0.5.3 indicates it does
something when you send NameService on to it:

 else if(!strcmp(identifier, "NameService"))
        return CORBA_Object_duplicate(orb->naming, ev);

orb->naming being set through naming_ior or naming_addr. I don't know if
this code is actually being used but it is there.

> Fetching a reference to GNOME's name service, at least, is done with
> Gnorba's gnome_name_service_get().  I don't think there is some elegant

I thought the name service IOR for gnome came through X hints.. I can't
use hints as I have a real distributed operation here. However, setting
the IOR through orbitrc or through the commandline would be an initial
solution, though I would have to fill this out manually until the time
came where I'd have persistent object being started up by orbit (if this
ever gets done :-)

I suppose nobody has effectively used orbitrc or argv parameters to poison
NameService so far, however.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311