Re: [Orbit-python-list] RootPOA
Status: Inactive
Brought to you by:
tack
From: Jason T. <ta...@li...> - 2000-11-30 00:28:35
|
> 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. |