Issue 3348: Python Issue: Dynamic Skeleton Interface (python-ftf) Source: Camros Corporation (Mr. Jeffrey A. Marshall, jam@camros.com) Nature: Uncategorized Issue Severity: Summary: Section 1.5.2 describes the "repository_id" parameter passed to PortableServer.DynamicImplementation.invoke as specifying the interface type for which the operation was called. How is the ORB able to deterimine this information? Does this really make sense anyway? Is it the repository id of the most derived interface or for the current call? There is no document describing what (if any) operations are ORB provided on PortableServer.DynamicImplementation. For example, it makes sense to provide default implementations of the following operations: - _is_a - _get_interface - _get_domain_managers Also, does it make sense to have the programmer over-ride a "_repository_id" or "_most_derived_interface" operation on this class in order to generate object references which don't require the client to invoke "_is_a" on (in order to narrow the reference)? Otherwise most calls to a python DynamicImplementation would result in the client always invoking _is_a in order to narrow. Resolution: The observation is correct, the ORB cannot supply the repository_id. Specifying that the servant mus Revised Text: The observation is correct, the ORB cannot supply the repository_id. Specifying that the servant must implement _get_interface solves all aspects of this issue Revised Text: In 1.5.2, delete the bullet item a keyword parameter repository_id, specifying the interface type for which the operation was called. At the end of section 1.5.2, add the sentence The implementation class must also implement the pseudo-operation _get_interface, which must return a non-nil CORBA::InterfaceDef reference. It does not need to implement any other pseudo operation. Actions taken: February 22, 2000: received issue October 10, 2000: closed sisue Discussion: End of Annotations:===== Date: Tue, 22 Feb 2000 15:45:15 -0500 (EST) Message-Id: <200002222045.PAA22270@emerald.omg.org> To: python-ftf@omg.org, issues@omg.org Subject: Python Issue: Dynamic Skeleton Interface From: "Jeffrey A. Marshall" X-Mailer: TWIG 2.1.1 Content-Type: text X-UIDL: e[4!!,mP!!@old9l^!"! Section 1.5.2 describes the "repository_id" parameter passed to PortableServer.DynamicImplementation.invoke as specifying the interface type for which the operation was called. How is the ORB able to deterimine this information? Does this really make sense anyway? Is it the repository id of the most derived interface or for the current call? There is no document describing what (if any) operations are ORB provided on PortableServer.DynamicImplementation. For example, it makes sense to provide default implementations of the following operations: - _is_a - _get_interface - _get_domain_managers Also, does it make sense to have the programmer over-ride a "_repository_id" or "_most_derived_interface" operation on this class in order to generate object references which don't require the client to invoke "_is_a" on (in order to narrow the reference)? Otherwise most calls to a python DynamicImplementation would result in the client always invoking _is_a in order to narrow. -- Jeffrey A. Marshall Camros Corporation Email jam@camros.com Voice 703-876-1700 ext. 10 Fax 703-876-1818 http://www.camros.com/ Date: Wed, 29 Mar 2000 19:20:31 +0200 Message-Id: <200003291720.TAA26374@pandora> From: Martin von Loewis To: python-ftf@omg.org Subject: Issue 3348: Dynamic Skeleton Interface User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII X-UIDL: 7""!!(M0!!Wa*!!:WUd9 > Section 1.5.2 describes the "repository_id" parameter passed to > PortableServer.DynamicImplementation.invoke as specifying the > interface type for which the operation was called. How is the ORB > able to deterimine this information? Does this really make sense > anyway? I think this objection is correct; the ORB has no way of knowing what the interface is which the client meant to use. The issue also points out that support for pseudo-operations is not discussed. I found that requiring _get_interface should be sufficient: The implementation class (i.e. the one inheriting from DynamicImplementation) must implement the _get_interface pseudo-operation, returning a non-nil InterfaceDef reference. Implementations for all other pseudo-operations are provided in the DynamicImplementation. Implementing _get_interface in a DSI is trivial if an InterfaceRepository is available: Just lookup the repository id, and return the resulting InterfaceDef. The ORB can use this mechanism both to learn the operation signatures, and to implement _is_a itself. Comments? Martin