Issue 3015: why was is_abstract added to structs in CORBA IR? (orb_revision) Source: (, ) Nature: Clarification Severity: Summary: I was wondering if anyone can explain the rationale for adding the field 'is_abstract' to the CORBA::InterfaceDescription and CORBA::InterfaceDef::FullInterfaceDescription struct types in the CORBA 2.3 Interface Repository specification. (I do know about abstract interfaces, I am really looking for the rationale for breaking backwards compabitility). Basically, a CORBA 2.3 client using stubs compiled from the latest IDL cannot interoperate using IIOP with the Interface Repository of a pre-CORBA 2.3 ORB, because virtually any client of the IR will want to obtain a FullInterfaceDescription from an InterfaceDef, and a pre-CORBA 2.3 ORB will not marshal the 'is_abstract' field for the description struct, thereby the CORBA 2.3 client will fail to unmarshal the struct. Resolution: flagged as urgent....resolved Revised Text: 0. Add a new minor code <foo> to the BAD_PARAM exception in Section 3.17.2, that says "Attempt to derive abstract interface from non-abstract base interface in the Interface Repository". [Note: This is necessary to cover for the fact that someone could try to AbstractInterfaceDef::_set_base_interfaces with an InterfaceDefSeq that contains an InterfaceDef that is not an AbstractInterfaceDef.] 1. Add a new enum value dk_AbstractInterface to CORBA::DefinitionKind. This is used as the value returned by the inherited def_kind attribute. 2. add create_abstract_interface to CORBA::Container AbstractInterfaceDef create_abstract_interface( in RepositoryId id, in Identifier name, in VersionSpec version in AbstractInterfaceDefSeq base_interfaces ); and add the following text description: The create_abstract_interface operation returns a new empty AbstractInterfaceDef with the specified base_interfaces. Other types can be added in the same way as InterfaceDef allows types to be added. 3. Add a new section 10.5.xx as follows 10.5.xx AbstractInterfaceDef An AbstractInterfaceDef object represents a CORBA 2.3 abstract interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. *Its base interfaces can only contain AbstractInterfaceDefs.* module CORBA { interface AbstractInterfaceDef; typedef sequence<AbstractInterfaceDef> AbstractInterfaceDefSeq; interface AbstractInterfaceDef : InterfaceDef { }; 10.5.xx.1 Read Interface [Note: I have filled in the actual text describing the operations from the corresponding text in InterfaceDef, so that minor changes can be made to the text to account for minor differences.] The inherited base_interfaces attribute returns a list of abstract interfaces from which this abstract interface inherits. Note: base_interfaces is of type InterfaceDefSeq, but since AbstractInterfaceDef is derived from InterfaceDef, a list of AbstractInterfaceDefs can legitimately be returned in an InterfaceDefSeq. The inherited is_a operation returns TRUE if the interface on which it is invoked either is identical to or inherits, directly or indirectly, from the abstract interface identified by its interface_id parameter, or if the value of interface_id is IDL:omg.org/CORBA/AbstractBase:1.0 . Otherwise it returns FALSE. The inherited describe_interface operation returns a FullInterfaceDescription describing the abstract interface, including its operations and attributes. The inherited describe operation for an AbstractInterfaceDef returns an InterfaceDescription. The inherited contents operation returns the list of constants, typedefs, and exceptions defined in this AbstractInterfaceDef and the list of attributes and operations either defined or inherited in this AbstractInterfaceDef. If the exclude_inherited parameter is set to TRUE, only attributes and operations defined within this interface are returned. If the exclude_inherited parameter is set to FALSE, all attributes and operations are returned. 10.5.xx.2 Write Interface Setting the inherited base_interfaces attribute causes a BAD_PARAM exception with standard minor code 5 to be raised if the name attribute of any object contained by this AbstractInterfaceDef conflicts with the name attribute of any object contained by any of the specified base AbstractInterfaceDefs. *If any of the InterfaceDefs in base_interface are not AbstractInterfaceDefs then a BAD_PARAM exception with standard minor code <foo> is raised.* The inherited create_attribute operation returns a new AttributeDef contained in the AbstractInterfaceDef on which it is invoked. The id, name, version, type_def, and mode attributes are set as specified. The type attribute is also set. The defined_in attribute is initialized to identify the containing AbstractInterfaceDef. An error is returned if an object with the specified id already exists within this object’s Repository, or if an object with the specified name already exists within this AbstractInterfaceDef. The inherited create_operation operation returns a new OperationDef contained in the AbstractInterfaceDef on which it is invoked. The id, name, version, result_def, mode, params, exceptions, and contexts attributes are set as specified. The result attribute is also set. The defined_in attribute is initialized to identify the containing AbstractInterfaceDef. An error is returned if an object with the specified id already exists within this object’s Repository, or if an object with the specified name already exists within this AbstractInterfaceDef. 4. Make the following changes to section 10.5.23: First paragraph: restore it to as it was before 2.3. An InterfaceDef object represents an interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. IDL: restore this part to as it appeared in CORBA 2.2. module CORBA { interface InterfaceDef; typedef sequence <InterfaceDef> InterfaceDefSeq; typedef sequence <RepositoryId> RepositoryIdSeq; typedef sequence <OperationDescription> OpDescriptionSeq; typedef sequence <AttributeDescription> AttrDescriptionSeq; interface InterfaceDef : Container, Contained, IDLType { // read/write interface attribute InterfaceDefSeq base_interfaces; // read interface boolean is_a (in RepositoryId interface_id); struct FullInterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; OpDescriptionSeq operations; AttrDescriptionSeq attributes; RepositoryIdSeq base_interfaces; TypeCode type; }; FullInterfaceDescription describe_interface(); // write interface AttributeDef create_attribute ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType type, in AttributeMode mode ); OperationDef create_operation ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType result, in OperationMode mode, in ParDescriptionSeq params, in ExceptionDefSeq exceptions, in ContextIdSeq contexts ); }; struct InterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; RepositoryIdSeq base_interfaces; }; }; Read interface: Remove the description of the is_abstract attribute. 7. Remove all version pragmas from all IFR related IDL. [Note: This is necessary in order to make sure that a 2.2 InterfaceDef is not rejected as not equivalent to t 2.3 InterfaceDef. Admittedly this is a bit hokey since a 2.3 InterfaceDef derives from a 2.3 Container and hence has additional operations through derivation when compared to 2.2 InterfaceDef, but from an interoperability and backward compatibility perspective this is relatively benign since a 2.3 client attempting to invoke a 2.3 operation on a 2.2 IFR will merely get a BAD_OPERATION. A 2.2 client will never be able to invoke a 2.3 operation anyway. There are cases where a 2.2 client may get back a 2.3 IRObject containing a dk_* value that is unknown to the 2.2 client. In the better written ORBs these will cause MARSHAL exception due to failure to unmarshal the unknown value of an enumerator. In other ORBs the client may have a problem if it is not programmed defensively.] Actions taken: November 9, 1999: received issue February 4, 2000: closed issue Discussion: Adding the is_abstract member to the Structs InterfaceDescription and FullInterfaceDescription and associated changes to the InterfaceDef interface was an error. The correct way to do this is shown below. A proper resolution to 3015 should recognize that because Abstract Interfaces are a distinct type in IDL, they should be their own type in the IFR as well. This distinction has already been addressed in TypeCodes with create_abstract_interface_tc and tk_abstract_interface. Because the behaviors of interfaces and abstract interfaces are very different, this should also be stressed in the IFR. Consequently, in keeping with the general pattern established with the way abstract interfaces are handled in TypeCodes, it is porposed that AbstractInterfaceDef be defined as an IFR object that represents Abstract Interfaces, and that otherwise has all the attribtues, operations and properties similar to InterfaceDef. This is represented by having AbstractInterfaceDef derive from InterfaceDef, sort of recognizing that an AbstractInterfaceDef IR Object is an InterfaceDef of a special restricted kind. It is necessary to ensure, however, that the base_interfaces of AbstractInterfaceDefs only contain AbstractInterfaceDefs. Also, It is necessary to remove version pragmas at least from InterfaceDef in order to make sure that a 2.2 InterfaceDef is not rejected as not equivalent to a 2.3 InterfaceDef. Admittedly this is a bit hokey since a 2.3 InterfaceDef derives from a 2.3 Container and hence has additional operations through derivation when compared to 2.2 InterfaceDef, but from an interoperability and backward compatibility perspective this is relatively benign since a 2.3 client attmepting to invoke a 2.3 operation on a 2.2 IFR will merely get a BAD_OPERATION. A 2.2 client will never be able to invoke a 2.3 operation anyway. Since it would then be absurd for a 2.2 (aka 1.0) InterfaceDef to be deriving from a 2.3 Container, it is necessary to remove version pragmas from the transitive closure of the dependency graph for InterfaceDef. It is much easier to remove all version pragmas from IFR interfaces and other IDL entities. It is acknowledged that this is not a complete and clean resolution, but it is also acknowledged that it is impossible to fix all version problems that have accumulated in the IFR due to past carelessness. With these changes, it is believed that pre-2.3 and 2.3 IFR are able to interoperate compatibly with pre 2.3 or 2.3 clients. Future enhancements to IFR should be carried out with greater care and with more attention towards compatibility and cleanliness of versioning. End of Annotations:===== `Date: Wed, 10 Nov 1999 10:22:15 +1300 From: Evan Ireland Organization: Sybase, Inc. X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 Newsgroups: comp.object.corba To: issues@omg.org Subject: CORBA 2.3 gurus: why was is_abstract added to structs in CORBA IR? Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $jo!!#ked9cA;e9DDmd9 Hi there CORBA 2.3 gurus. I was wondering if anyone can explain the rationale for adding the field 'is_abstract' to the CORBA::InterfaceDescription and CORBA::InterfaceDef::FullInterfaceDescription struct types in the CORBA 2.3 Interface Repository specification. (I do know about abstract interfaces, I am really looking for the rationale for breaking backwards compabitility). Basically, a CORBA 2.3 client using stubs compiled from the latest IDL cannot interoperate using IIOP with the Interface Repository of a pre-CORBA 2.3 ORB, because virtually any client of the IR will want to obtain a FullInterfaceDescription from an InterfaceDef, and a pre-CORBA 2.3 ORB will not marshal the 'is_abstract' field for the description struct, thereby the CORBA 2.3 client will fail to unmarshal the struct. Is it too late for this to be fixed in CORBA 2.3? ________________________________________________________________________________ Evan Ireland Sybase EA Server Engineering eireland@sybase.com Wellington - New Zealand +64 4 934-5856 Sender: jis@fpk.hp.com Message-ID: <3828A27F.D729F84E@fpk.hp.com> Date: Tue, 09 Nov 1999 17:38:55 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: orb_revision@omg.org Subject: OBV strikes again!:-) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %BG!!hL0e95=?!!@([d9 Just FYI. This is an issue heading our way. > Hi there CORBA 2.3 gurus. > > I was wondering if anyone can explain the rationale for adding the > field > 'is_abstract' to the CORBA::InterfaceDescription and > CORBA::InterfaceDef::FullInterfaceDescription struct types in the > CORBA > 2.3 Interface Repository specification. (I do know about abstract > interfaces, > I am really looking for the rationale for breaking backwards > compabitility). > > Basically, a CORBA 2.3 client using stubs compiled from the latest > IDL cannot > interoperate using IIOP with the Interface Repository of a pre-CORBA > 2.3 ORB, > because virtually any client of the IR will want to obtain a > FullInterfaceDescription from an InterfaceDef, and a pre-CORBA 2.3 > ORB will > not marshal the 'is_abstract' field for the description struct, > thereby the > CORBA 2.3 client will fail to unmarshal the struct. > > Is it too late for this to be fixed in CORBA 2.3? > ________________________________________________________ > > Evan Ireland Sybase EA Server Engineering > eireland@sybase.com > Wellington - New Zealand > +64 4 934-5856 Well, (i) we could ask the OBV submitters for the rationale adn hear something like - Oh whoever uses the IR anyway?:-), and (ii) So what can be done in 2.3? We could add a 2.2 compatibility IR interfaces to 2.3, that 2.3 clients can use to get to 2.2. I would look something like: module IR22Compatibility { The entire 2.2 IR interfaces with tweaks to fit in with 2.3 }; Instructions to use these interfaces if talking to a 2.2 IR. But this is a bad patching the problem at best. Comments? Jishnu. Comments? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Wed, 10 Nov 1999 09:13:26 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: OBV strikes again!:-) References: <3828A27F.D729F84E@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,9^d9Gm$"!DJP!!#MEe9 Jishnu, The 2.3 IR interfaces were versioned for exactly this reason. When talking to a 2.2 IR, 2.2 stubs generated from 2.2 IDL must be used. When talking to a 2.3 IR, 2.3 stubs generated from 2.3 IDL must be used. If 2.3 stubs are used to talk to a 2.2 IR, the version mismatch in the repid wil cause "narrow" to fail, which provides a clear indication of the incompatibility. If a 2.3 client wishes to talk to both a 2.3 IR and a 2.2 IR, it needs to have both sets of stubs. In Java, this can be done using the nonstandard "package prefix" mechanism supported by most or all IDL compilers. I do not think there is any problem here that needs fixing. Simon Jishnu Mukerji wrote: > > Just FYI. This is an issue heading our way. > > > Hi there CORBA 2.3 gurus. > > > > I was wondering if anyone can explain the rationale for adding the > field > > 'is_abstract' to the CORBA::InterfaceDescription and > > CORBA::InterfaceDef::FullInterfaceDescription struct types in the > CORBA > > 2.3 Interface Repository specification. (I do know about abstract > interfaces, > > I am really looking for the rationale for breaking backwards > compabitility). > > > > Basically, a CORBA 2.3 client using stubs compiled from the latest > IDL cannot > > interoperate using IIOP with the Interface Repository of a > pre-CORBA 2.3 ORB, > > because virtually any client of the IR will want to obtain a > > FullInterfaceDescription from an InterfaceDef, and a pre-CORBA 2.3 > ORB will > > not marshal the 'is_abstract' field for the description struct, > thereby the > > CORBA 2.3 client will fail to unmarshal the struct. > > > > Is it too late for this to be fixed in CORBA 2.3? > > ________________________________________________________ > > > > Evan Ireland Sybase EA Server Engineering > > eireland@sybase.com > > Wellington - New Zealand > > +64 4 934-5856 > > Well, (i) we could ask the OBV submitters for the rationale adn hear > something > like - Oh whoever uses the IR anyway?:-), and (ii) So what can be > done in 2.3? > > We could add a 2.2 compatibility IR interfaces to 2.3, that 2.3 > clients can use > to get to 2.2. > > I would look something like: > > module IR22Compatibility { > > The entire 2.2 IR interfaces with tweaks to fit in with 2.3 > > }; > > Instructions to use these interfaces if talking to a 2.2 IR. But > this is a bad > patching the problem at best. > > Comments? > > Jishnu. > > Comments? > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jis@fpk.hp.com Message-ID: <38298D6D.33C6A9D8@fpk.hp.com> Date: Wed, 10 Nov 1999 10:21:17 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Simon Nash CC: orb_revision@omg.org Subject: Re: OBV strikes again!:-) References: <3828A27F.D729F84E@fpk.hp.com> <38293736.D237841D@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b%6!!:)He9([\!!=D~!! Simon Nash wrote: > > Jishnu, > The 2.3 IR interfaces were versioned for exactly this reason. > > When talking to a 2.2 IR, 2.2 stubs generated from 2.2 IDL must be > used. > When talking to a 2.3 IR, 2.3 stubs generated from 2.3 IDL must be > used. > If 2.3 stubs are used to talk to a 2.2 IR, the version mismatch in > the repid > wil cause "narrow" to fail, which provides a clear indication of the > incompatibility. > > If a 2.3 client wishes to talk to both a 2.3 IR and a 2.2 IR, it > needs > to have both sets of stubs. In Java, this can be done using the > nonstandard > "package prefix" mechanism supported by most or all IDL compilers. > > I do not think there is any problem here that needs fixing. Well, my recollection is that the OBV submitters submitted a non-backward compatible change to the IR interfaces, and did not say anything about versioning. Versioning is something that I shoehorned in later. Ideally, we should have made sure that either the changes wewre backward compatible by using the subclassing technique or placed the new version of the IR interfaces in a separate module. But that is much water under the bridge. The bottom line is that at present there is no "standard" way of dealing with this, even in Java (by your own admission). So what the people are stuck with now is a situation where client code must contain a version test and then have both kinds of stubs available to them in some form. I have no idea how you do this in C++ for example, certain name clash issues come to mind. So to say that there is no problem is taking the proverbial Ostrich approach at best. Looks like we have created a product opportunity! An IR access library that consists of "smart" stubs that do this work for the client, would be the most ideal thing. ORB/IR vendors, are you listening/reading? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: Paul Kyzivat To: "'jis@fpk.hp.com'" , "'Simon Nash'" Cc: "'orb_revision@omg.org'" Subject: RE: OBV strikes again!:-) Date: Wed, 10 Nov 1999 13:04:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 7U%e9R)jd965:!!3YXd9 > Looks like we have created a product opportunity! An IR > access library that consists of "smart" stubs that do this > work for the client, would be the most ideal thing. > ORB/IR vendors, are you listening/reading? This assumes you believe that poking thru an IR at runtime is a desirable thing to do. Date: Wed, 10 Nov 1999 23:28:31 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: OBV strikes again!:-) References: <3828A27F.D729F84E@fpk.hp.com> <38293736.D237841D@hursley.ibm.com> <38298D6D.33C6A9D8@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: PEmd9j?"!!`X5!!1lkd9 Jishnu, Jishnu Mukerji wrote: > > Simon Nash wrote: > > > > Jishnu, > > The 2.3 IR interfaces were versioned for exactly this reason. > > > > When talking to a 2.2 IR, 2.2 stubs generated from 2.2 IDL must be > used. > > When talking to a 2.3 IR, 2.3 stubs generated from 2.3 IDL must be > used. > > If 2.3 stubs are used to talk to a 2.2 IR, the version mismatch in > the repid > > wil cause "narrow" to fail, which provides a clear indication of > the > > incompatibility. > > > > If a 2.3 client wishes to talk to both a 2.3 IR and a 2.2 IR, it > needs > > to have both sets of stubs. In Java, this can be done using the > nonstandard > > "package prefix" mechanism supported by most or all IDL compilers. > > > > I do not think there is any problem here that needs fixing. > > Well, my recollection is that the OBV submitters submitted a > non-backward > compatible change to the IR interfaces, and did not say anything > about > versioning. Versioning is something that I shoehorned in > later. Ideally, we > should have made sure that either the changes wewre backward > compatible by using > the subclassing technique or placed the new version of the IR > interfaces in a > separate module. But that is much water under the bridge. > > The bottom line is that at present there is no "standard" way of > dealing with > this, even in Java (by your own admission). So what the people are > stuck with > now is a situation where client code must contain a version test and > then have > both kinds of stubs available to them in some form. I have no idea > how you do > this in C++ for example, certain name clash issues come to mind. So > to say that > there is no problem is taking the proverbial Ostrich approach at > best. > If you believe there is a problem then I am surprised that you > proposed the IR versioning approach knowing that it was "broken." A subclassing > approach would probably have been better, but as you say that is now water > under the bridge. On a more constructive note, I think the best short-term > solution for Java is to standardize the "package prefix" concept in the IDL to Java > mapping. Since most or all vendors already support this, it should not be > controversial. I will defer to a C++ expert for suggestions on how the stub name > clash problem could be handled in the C++ bindings. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jis@fpk.hp.com Message-ID: <382AE3A2.34F350B5@fpk.hp.com> Date: Thu, 11 Nov 1999 10:41:22 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Simon Nash Cc: orb_revision@omg.org Subject: Re: OBV strikes again!:-) References: <3828A27F.D729F84E@fpk.hp.com> <38293736.D237841D@hursley.ibm.com> <38298D6D.33C6A9D8@fpk.hp.com> <3829FF9F.C38858B1@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: H&f!!l`o!!,*Pe9WLld9 Simon Nash wrote: > If you believe there is a problem then I am surprised that you > proposed the > IR versioning approach knowing that it was "broken." It was not for me to propose that. It would have been done by the OMG editorial staff, if I had not said anything about it too. Interfaces that have changed are supposed to have their version number changed according to standard procedure that exists today. > On a more constructive note, I think the best short-term solution for > Java is to standardize the "package prefix" concept in the IDL to Java mapping. > Since most or all vendors already support this, it should not be controversial. > I will defer to a C++ expert for suggestions on how the stub name clash problem > could be handled in the C++ bindings. That can be discussed as a possibility as soon as someone writes up a concise proposal, and then we can see if it flies. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jon@floorboard.com Message-ID: <382AE84E.8416F61A@floorboard.com> Date: Thu, 11 Nov 1999 08:01:18 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Jishnu Mukerji , orb_revision@omg.org Subject: Re: OBV strikes again!:-) References: <3828A27F.D729F84E@fpk.hp.com> <38293736.D237841D@hursley.ibm.com> <38298D6D.33C6A9D8@fpk.hp.com> <3829FF9F.C38858B1@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]e)!!&Vjd9!KH!!Ad If you believe there is a problem then I am surprised that you > proposed the > IR versioning approach knowing that it was "broken." A subclassing > approach > would probably have been better, but as you say that is now water > under the > bridge. On a more constructive note, I think the best short-term > solution for > Java is to standardize the "package prefix" concept in the IDL to > Java mapping. > Since most or all vendors already support this, it should not be > controversial. > I will defer to a C++ expert for suggestions on how the stub name > clash problem > could be handled in the C++ bindings. Of course, there are languages besides C++ and Java, aren't there? :-) Seriously, the C++ mapping could use almost exactly the same approach by mapping to a "namespace prefix". The same goes for Ada mapping to packages. C isn't really a problem anyway, since all generated names just have the entire IDL scope separated by underscores, so you can just add a prefix to that as well. This leaves Smalltalk & Cobol, but that is definately beyond my area of expertise. This would solve the versioning problem for non-interfaces, at least for stuff embedded in a module. Anyone who doesn't embed their IDL in a module deserves to be shot anyway. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org To: Jonathan Biggar cc: Simon Nash , Jishnu Mukerji , orb_revision@omg.org Subject: Re: OBV strikes again!:-) In-reply-to: Your message of "Thu, 11 Nov 1999 08:01:18 PST." <382AE84E.8416F61A@floorboard.com> Date: Thu, 11 Nov 1999 16:18:40 PST Sender: Bill Janssen From: Bill Janssen Message-Id: <99Nov11.161840pst."3638"@watson.parc.xerox.com> Content-Type: text X-UIDL: TU_d9n#0!!0Z;e9/@8!! In message <382AE84E.8416F61A@floorboard.com>you write: >This leaves Smalltalk & Cobol... And Python! Bill Sender: jis@fpk.hp.com Message-ID: <3855808D.FB8181F7@fpk.hp.com> Date: Mon, 13 Dec 1999 18:26:05 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: orb_revision@omg.org Cc: Simon Nash Subject: Issue 3015 proposed resolution Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b~;!!!Z]!!H2ad9[2~!! Simon Nash wrote: > > Jishnu, > > Jishnu Mukerji wrote: > > > > I was wondering if we should simply stuff the new create_* > operations in > > the Container interface without using a derived interface. My > > inclination is to use the "create_* operations are not supposed to > be > > accessed from random early release clients" defence to say that we > just > > add the new operations to Container as it stands for this time, > because > > using derived Container entails essentially making new versions of > the > > entire lot of Container derived Def interfaces. Maybe we will do > that in > > Components FTF, but not now. This means that when a 2.3 client > tries to > > invoke any of the new operations on a 2.0 server, they will fail > with a > > BAD_OPERATION, not a very hopeless situation. If done correctly, > the 2.3 > > client would have failed to narrow Container to notionally > Container_2_3 > > and hence would have been unable to make the call. > > > > Also, any opinions on the Repository interface, to which we also > added > > an operation in 2.3. That one is pretty benign I think because > currently > > nothing derives from Repository. But the failure mode is similar > to the > > Container case, and hence can be fudged > > > > Also, is it the consensus that we should add all the new > operations to > > the CORBA module and hold off on separate module until Components? > > > > Yes, I think we should do all the above because CORBA 2.3 has > already been > published and we should therefore only make changes to the published > spec at > this point if we need to fix things that are seriously broken, e.g., > the > InterfaceDef problem. For the other 2.3 additions on your list, the > cure > (changing the published 2.3 specs) is worse than the disease. I have one further question. Do we really need InterfaceDescription_2_3? I think it would be OK for describe() to return the old InterfaceDescription, while someone interested in the full 2.3 description can always get it through the describe_interface_2_3 operation. Anyway, for now, here is the proposed resolution (based on Simon's text) for 3015. Please comment on it before we put it to vote in vote 8. Issue 3015: why was is_abstract added to structs in CORBA IR? (orb_revision) Resolution: Adding the is_abstract member to the Structs InterfaceDescription and FullInterfaceDescription and associated changes to the InterfaceDef interface was an error. The correct way to do this is shown below, and it is proposed that this be incorporated in CORBA 2.3 in a dot release. Revised Text: 1. Add a new enum value dk_Interface_2_3 to DefinitionKind. This is used as the kind member of the Description struct returned by the inherited describe operation of InterfaceDef_2_3, and indicates that the associated struct is an FullInterfaceDescription_2_3. 2. In Container, change create_interface to: InterfaceDef create_interface ( in RepositoryId id, in Identifier name, in VersionSpec version, in InterfaceDefSeq base_interfaces, ); and add a new method create_interface_2_3 defined as: InterfaceDef_2_3 create_interface_2_3 ( in RepositoryId id, in Identifier name, in VersionSpec version, in InterfaceDefSeq base_interfaces, in boolean is_abstract ); and add the following text description: The create_interface_2_3 operation returns a new empty InterfaceDef_2_3 with the specified base_interfaces. Type, exception, and constant definitions can be added using Container::create_ operations on the new InterfaceDef. OperationDefs can be added using InterfaceDef::create_operation and AttributeDefs can be added using Interface::create_attribute. Definitions can also be added using the Contained::move operation. 3. Make the following changes to section 10.5.23: First paragraph: An InterfaceDef object represents a pre-CORBA 2.3 interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. IDL: Restore this part to as it appeared in CORBA 2.2. module CORBA { interface InterfaceDef; typedef sequence InterfaceDefSeq; typedef sequence RepositoryIdSeq; typedef sequence OpDescriptionSeq; typedef sequence AttrDescriptionSeq; interface InterfaceDef : Container, Contained, IDLType { // read/write interface attribute InterfaceDefSeq base_interfaces; // read interface boolean is_a (in RepositoryId interface_id); struct FullInterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; OpDescriptionSeq operations; AttrDescriptionSeq attributes; RepositoryIdSeq base_interfaces; TypeCode type; }; FullInterfaceDescription describe_interface(); // write interface AttributeDef create_attribute ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType type, in AttributeMode mode ); OperationDef create_operation ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType result, in OperationMode mode, in ParDescriptionSeq params, in ExceptionDefSeq exceptions, in ContextIdSeq contexts ); }; struct InterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; RepositoryIdSeq base_interfaces; }; }; Read interface: Remove the description of the is_abstract attribute. 4. Add a new section 10.5.xx as follows: 10.5.xx InterfaceDef_2_3 An InterfaceDef_2_3 object represents a CORBA 2.3 interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. module CORBA { interface InterfaceDef_2_3 : InterfaceDef { // read/write interface attribute boolean is_abstract; // read interface struct FullInterfaceDescription_2_3 { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; OpDescriptionSeq operations; AttrDescriptionSeq attributes; RepositoryIdSeq base_interfaces; TypeCode type; boolean is_abstract; }; FullInterfaceDescription_2_3 describe_interface_2_3(); }; struct InterfaceDescription_2_3 { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; RepositoryIdSeq base_interfaces; boolean is_abstract; }; }; 10.5.xx.1 Read Interface The is_abstract attribute is TRUE if the interface is an abstract interface type. The describe_interface_2_3 operation returns a FullInterfaceDescription_2_3 describing the interface, including its operations and attributes. The operations and attributes fields of the FullInterfaceDescription_2_3 structure include descriptions of all of the operations and attributes in the transitive closure of the inheritance graph of the interface being described. The inherited describe operation for an InterfaceDef_2_3 returns an InterfaceDescription_2_3. Actions taken: Incorporate change and close issue -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Sender: andrew@emerald.omg.org Message-Id: Mime-Version: 1.0 Date: Tue, 18 Jan 2000 18:59:24 -0500 To: orb_revision@omg.org From: Andrew Watson Subject: Issue 3015 classified as Urgent Cc: Jeff Mischkinsky , Jishnu Mukerji , "Robert A. Kukura" , Tom Rutt , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Bill Beckwith , Paul Kyzivat , Ken Cavanaugh , Edward Cobb , Russell Butek , Yoshitaka Honishi , Vijay Natarajan , Nick Sharman , Jonathan Biggar , Linda Heaton Content-Type: text/plain; charset="us-ascii" X-UIDL: 2-0!!EGV!!S+`d9,"Xd9 Good Evening, At Jishnu's request I am classifying Issue 3015 (IFR backward compatibility fix) as Urgent and assigning it to the CORBA core RTF. This is being done so that it can be incorporated into CORBA 2.3.x as soon as possible. The default resolution for this issue is attached. This is *exactly* the resolution that was recently passed by the old core RTF, so classifying it as urgent is merely a pro-forma exercise to get it into the next minor revision to CORBA 2.3.x. The deadline for this urgent issue expires in two weeks, on Tuesday 1st Feb. If the RTF takes no action then the exisiting resolution to 3015 will come into effect for CORBA 2.3.1 on that day (and be incorporated into a new minor revision - 2.3.2? - shortly afterwards). If anyone on the RTF feels that an urgent resolution to this issue should for some reason be different to the already-agreed non-urgent resolution, please get in touch with Jishnu and myself ASAP. Aren't procedural gymnastics fun? :-) Cheers, Andrew Default urgent resolution to Issue 3015 --------------------------------------- Summary: Adding the is_abstract member to the Structs InterfaceDescription and FullInterfaceDescription and associated changes to the InterfaceDef interface was an error. The correct way to do this is shown below, and it is proposed that this be incorporated in CORBA 2.3 in a dot release. Revised Text: 1. Add a new enum value dk_Interface_2_3 to DefinitionKind. This is used as the kind member of the Description struct returned by the inherited describe operation of InterfaceDef_2_3, and indicates that the associated struct is an FullInterfaceDescription_2_3. 2. In Container, change create_interface to: InterfaceDef create_interface ( in RepositoryId id, in Identifier name, in VersionSpec version, in InterfaceDefSeq base_interfaces, ); and add a new method create_interface_2_3 defined as: InterfaceDef_2_3 create_interface_2_3 ( in RepositoryId id, in Identifier name, in VersionSpec version, in InterfaceDefSeq base_interfaces, in boolean is_abstract ); and add the following text description: The create_interface_2_3 operation returns a new empty InterfaceDef_2_3 with the specified base_interfaces. Type, exception, and constant definitions can be added using Container::create_ operations on the new InterfaceDef. OperationDefs can be added using InterfaceDef::create_operation and AttributeDefs can be added using Interface::create_attribute. Definitions can also be added using the Contained::move operation. 3. Make the following changes to section 10.5.23: First paragraph: An InterfaceDef object represents a pre-CORBA 2.3 interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. IDL: restore this part to as it appeared in CORBA 2.2. module CORBA { interface InterfaceDef; typedef sequence InterfaceDefSeq; typedef sequence RepositoryIdSeq; typedef sequence OpDescriptionSeq; typedef sequence AttrDescriptionSeq; interface InterfaceDef : Container, Contained, IDLType { // read/write interface attribute InterfaceDefSeq base_interfaces; // read interface boolean is_a (in RepositoryId interface_id); struct FullInterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; OpDescriptionSeq operations; AttrDescriptionSeq attributes; RepositoryIdSeq base_interfaces; TypeCode type; }; FullInterfaceDescription describe_interface(); // write interface AttributeDef create_attribute ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType type, in AttributeMode mode ); OperationDef create_operation ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType result, in OperationMode mode, in ParDescriptionSeq params, in ExceptionDefSeq exceptions, in ContextIdSeq contexts ); }; struct InterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; RepositoryIdSeq base_interfaces; }; }; Read interface: Remove the description of the is_abstract attribute. 4. Add a new section 10.5.xx as follows: 10.5.xx InterfaceDef_2_3 An InterfaceDef_2_3 object represents a CORBA 2.3 interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. module CORBA { interface InterfaceDef_2_3 : InterfaceDef { // read/write interface attribute boolean is_abstract; // read interface struct FullInterfaceDescription_2_3 { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; OpDescriptionSeq operations; AttrDescriptionSeq attributes; RepositoryIdSeq base_interfaces; TypeCode type; boolean is_abstract; }; FullInterfaceDescription_2_3 describe_interface_2_3(); }; struct InterfaceDescription_2_3 { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; RepositoryIdSeq base_interfaces; boolean is_abstract; }; }; 10.5.xx.1 Read Interface The is_abstract attribute is TRUE if the interface is an abstract interface type. The describe_interface_2_3 operation returns a FullInterfaceDescription_2_3 describing the interface, including its operations and attributes. The operations and attributes fields of the FullInterfaceDescription_2_3 structure include descriptions of all of the operations and attributes in the transitive closure of the inheritance graph of the interface being described. The inherited describe operation for an InterfaceDef_2_3 returns an InterfaceDescription_2_3. Date: Sun, 23 Jan 2000 18:30:09 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: orb_revision@omg.org, butek@us.ibm.com, andrew@omg.org Subject: Urgent issue 3015 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: V!/!!\UX!!kW0e92OA!! Jishnu, I noticed that the IDL in ptc/98-12-07 does not quite match the resolution adopted by the core RTF. The difference is that 98-12-07 contains lines such as #pragma version InterfaceDef 2.3 and the adopted IDL does not. I am hoping that this is an editorial oversight and can be corrected as such. Leaving these pragmas in the IDL is disastrous because it creates the same problem that 3015 was intended to solve, namely backwards incompatibility with the CORBA 2.2 IR. The problem is as follows. If a client's helper class for InterfaceDef was generated using a CORBA 2.2 orb.idl file, and the client attempts to narrow some object reference to InterfaceDef using this helper, it will ask the server if the type ID is "IDL:omg.org/CORBA/InterfaceDef:1.0". If the server's orb.idl file is the one published in 98-12-07, it will not recognize this type ID because it thinks the type ID for InterfaceDef is "IDL:omg.org/CORBA/InterfaceDef:2.3". Therefore the narrow will fail. Likewise a 2.3 client will be unable to narrow InterfaceDef objects on a 2.2 server. The correct fix to this problem is to back out all the #pragma version xxx 2.3 lines that were inserted by the original incorrect change. Is this within the bounds of editorial action? If not, we should incorporate this change into the resolution of the urgent issue that Andrew raised recently. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 24 Jan 2000 14:08:38 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash Cc: orb_revision@omg.org, butek@us.ibm.com, andrew@omg.org Subject: Re: Urgent issue 3015 References: <388B48B1.4DDE273E@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Fnad9QD2!!UO;e9/]""! > I noticed that the IDL in ptc/98-12-07 does not quite match the > resolution adopted by the core RTF. The difference is that 98-12-07 > contains lines such as > #pragma version InterfaceDef 2.3 > and the adopted IDL does not. > Yes, we need to figure out what to do with those version pragmas. The problem as usual is convoluted. InterfaceDef derives among other things, from Container, which has changed between 2.2 and 2.3 by virtue of the addition of ValueDef creation operation etc., hence Container is legitimately of a new version, which rightfully should have been done through derivation etc., but Simon and others didn't want to do that because that was too much change. Now then, if Container is versioned then InterfaceDef which is derived from that needs to be versioned too. However, I understand the issue that Simon is raising. The consistent across the board approach to this in the context of IFR is to remove all version pragmas and depend on the appropriate raising of BAD_OPERATION exception when a newer version client calls an older version server, something that already should work. I think it is worth documenting this decision adequately so that we do not go into the "IFR is not adequately versioned" discussion again. > I am hoping that this is an editorial oversight and can be corrected > as such. Leaving these pragmas in the IDL is disastrous because it > creates > the same problem that 3015 was intended to solve, namely backwards > incompatibility with the CORBA 2.2 IR. > See above. Actaully the resolution of 3015 was incomplete in this respect. We did not say anything about what is to be done with the version pragmas in the rest of IFR. So blindly putting it in effect would cause InterfaceDef:1.0 to be derived from Container:2.3, not a good thing. I think to be consistent we need to remove the version pragmas from at least everything that is involved in the declaration of InterfaceDef. The easiest way to do this would be to remove all version pragmas from IFR. If the collective feeling is leaning towards this, I will write up an alternate resolution to 3015, adding this to the rest of the resolution and then we will put it to vote say starting tomorrow, for a quick turnaround 3 day vote. Comments? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 24 Jan 2000 19:15:06 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: orb_revision@omg.org, butek@us.ibm.com, andrew@omg.org Subject: Re: Urgent issue 3015 References: <388B48B1.4DDE273E@hursley.ibm.com> <388CA336.17CB5D86@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Wo$!!%N6!!f3!e9bY,e9 Jishnu, > See above. Actaully the resolution of 3015 was incomplete in this respect. We > did not say anything about what is to be done with the version pragmas in the > rest of IFR. So blindly putting it in effect would cause InterfaceDef:1.0 to be > derived from Container:2.3, not a good thing. I think to be consistent we need > to remove the version pragmas from at least everything that is involved in the > declaration of InterfaceDef. The easiest way to do this would be to remove all > version pragmas from IFR. If the collective feeling is leaning towards this, I > will write up an alternate resolution to 3015, adding this to the rest of the > resolution and then we will put it to vote say starting tomorrow, for a quick > turnaround 3 day vote. > You are correct about the resolution being incomplete. I removed the version 2.3 pragmas from the IDL in my proposal, but I should have said explicitly that these would be removed everywhere. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 24 Jan 2000 11:44:45 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: Simon Nash , orb_revision@omg.org, butek@us.ibm.com, andrew@omg.org Subject: Re: Urgent issue 3015 References: <388B48B1.4DDE273E@hursley.ibm.com> <388CA336.17CB5D86@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: >B:e9/1a!!lf:!!7'@e9 Hi all, > However, I understand the issue that Simon is raising. The consistent across the > board approach to this in the context of IFR is to remove all version pragmas > and depend on the appropriate raising of BAD_OPERATION exception when a newer > version client calls an older version server, something that already should > work. If we are going to rely on BAD_OPERATION for Container, why do we have to complicate things for InterfaceDef. Why don't we add the following: // read/write interface attribute boolean is_abstract; // read interface struct FullInterfaceDescription_2_3 { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; OpDescriptionSeq operations; AttrDescriptionSeq attributes; RepositoryIdSeq base_interfaces; TypeCode type; boolean is_abstract; }; FullInterfaceDescription_2_3 describe_interface_2_3(); to the current InterfaceDef. Since we are adding new attributes and methods, they will exhibit the same behavior as the ValueDef creation operations. The addition of types should have no effect on backward compatibility. And of course, remove all the pragmas. Vijay X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 24 Jan 2000 15:31:07 -0500 To: Andrew Watson From: Steve Vinoski Subject: Re: Issue 3015 classified as Urgent Cc: orb_revision@omg.org, Linda Heaton In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: Kj3e9a_Yd9pEUd9K4Fe9 At 06:59 PM 1/18/00 -0500, Andrew Watson wrote: >Good Evening, > >At Jishnu's request I am classifying Issue 3015 (IFR backward compatibility >fix) as Urgent and assigning it to the CORBA core RTF. This is being done >so that it can be incorporated into CORBA 2.3.x as soon as possible. > >The default resolution for this issue is attached. This is *exactly* the >resolution that was recently passed by the old core RTF, so classifying it >as urgent is merely a pro-forma exercise to get it into the next minor >revision to CORBA 2.3.x. Having checked with Andrew and Jishnu about the legitimacy of proposing an alternative resolution to this urgent issue, and having received a positive reply from both, I would like the Core RTF to consider the following. A proper resolution to 3015 should recognize that because Abstract Interfaces are a distinct type in IDL, they should be their own type in the IFR as well. This distinction has already been addressed in TypeCodes with create_abstract_interface_tc and tk_abstract_interface. Because the behaviors of interfaces and abstract interfaces are very different, this should also be stressed in the IFR. The Interface_2_3 solution is messy, and if adopted could create even more problems down the road for the IFR and for Components (if they choose to use similar tactics for versioning other things). What happens when "local" interfaces are adopted? Are we going to add an Interface_3_0 to the CORBA spec? What about versions after 3.0? IMO we need to get this problem resolved as best as we possibly can. I believe the resolution proposed below to be superior to the resolution recently adopted by the Core RTF. Now that this issue is urgent, we have the ability to consider it fully one more time before adopting anything in haste. Please review the following and submit your comments. thanks, --steve Proposed Solution Revised Text: 1. Add a new enum value dk_AbstractInterface to CORBA::DefinitionKind. This is used as the kind member of the Description struct returned by the inherited describe operation. 2. add create_abstract_interface to CORBA::Container AbstractInterfaceDef create_abstract_interface( in RepositoryId id, in Identifier name, in VersionSpec version in AbstractInterfaceDefSeq base_interfaces ); and add the following text description: The create_abstract_interface operation returns a new empty AbstractInterfaceDef with the specified base_interfaces. Other types can be added in the same way as InterfaceDef allows types to be added. 3. Add a new section 10.5.xx as follows 10.5.xx AbstractInterfaceDef An AbstractInterfaceDef object represents a CORBA 2.3 abstract interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. module CORBA { interface AbstractInterfaceDef; typedef sequence AbstractInterfaceDefSeq; interface AbstractInterfaceDef : InterfaceDef { }; 10.5.xx.1 Read Interface The Read Interface for AbstractInterfaceDef types is the same as InterfaceDef. 10.5.xx.2 Write Interface The Write Interface for AbstractInterfaceDef types is the same as InterfaceDef. 4. Make the following changes to section 10.5.23: First paragraph: An InterfaceDef object represents a an interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. IDL: restore this part to as it appeared in CORBA 2.2. module CORBA { interface InterfaceDef; typedef sequence InterfaceDefSeq; typedef sequence RepositoryIdSeq; typedef sequence OpDescriptionSeq; typedef sequence AttrDescriptionSeq; interface InterfaceDef : Container, Contained, IDLType { // read/write interface attribute InterfaceDefSeq base_interfaces; // read interface boolean is_a (in RepositoryId interface_id); struct FullInterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; OpDescriptionSeq operations; AttrDescriptionSeq attributes; RepositoryIdSeq base_interfaces; TypeCode type; }; FullInterfaceDescription describe_interface(); // write interface AttributeDef create_attribute ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType type, in AttributeMode mode ); OperationDef create_operation ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType result, in OperationMode mode, in ParDescriptionSeq params, in ExceptionDefSeq exceptions, in ContextIdSeq contexts ); }; struct InterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; RepositoryIdSeq base_interfaces; }; }; Read interface: Remove the description of the is_abstract attribute. Date: Mon, 24 Jan 2000 20:31:47 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: jis@fpk.hp.com, orb_revision@omg.org, butek@us.ibm.com, andrew@omg.org Subject: Re: Urgent issue 3015 References: <388B48B1.4DDE273E@hursley.ibm.com> <388CA336.17CB5D86@fpk.hp.com> <388CABAD.9AEA4CBD@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2L^d9'5M!!$:Od9a$!!! Vijay, The only problem with this is that InterfaceDescription_2_3 has gone because there is no operation to obtain it. So we have lost the correspondence between InterfaceDescription/FullInterfaceDescription and the same pair of 2.3 versioned equivalents. Simon Vijaykumar Natarajan wrote: > > Hi all, > > > However, I understand the issue that Simon is raising. The > consistent across the > > board approach to this in the context of IFR is to remove all > version pragmas > > and depend on the appropriate raising of BAD_OPERATION exception > when a newer > > version client calls an older version server, something that > already should > > work. > > If we are going to rely on BAD_OPERATION for Container, why do we > have to complicate > things for InterfaceDef. > Why don't we add the following: > // read/write interface > attribute boolean is_abstract; > // read interface > struct FullInterfaceDescription_2_3 { > Identifier name; > RepositoryId id; > RepositoryId defined_in; > VersionSpec version; > OpDescriptionSeq operations; > AttrDescriptionSeq attributes; > RepositoryIdSeq base_interfaces; > TypeCode type; > boolean is_abstract; > }; > FullInterfaceDescription_2_3 describe_interface_2_3(); > to the current InterfaceDef. Since we are adding new attributes and > methods, they > will exhibit the same behavior as > the ValueDef creation operations. The addition of types should have > no effect on > backward compatibility. And of course, remove all the pragmas. > > Vijay -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: jis@fpk.hp.com cc: orb_revision@omg.org, andrew@omg.org Message-ID: <85256870.0070D1ED.00@d54mta08.raleigh.ibm.com> Date: Mon, 24 Jan 2000 14:26:22 -0600 Subject: Re: Urgent issue 3015 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: `E0!!OJH!!d#Ce9968!! Jishnu, Just to make a bit more noise, the collective feeling, at least at IBM, is definitely leaning towards removing all version pragmas from IFR. That's what I'd vote for. Russell Butek butek@us.ibm.com Jishnu Mukerji on 01/24/2000 01:08:38 PM Please respond to jis@fpk.hp.com To: Simon Nash cc: orb_revision@omg.org, Russell Butek/Austin/IBM@IBMUS, andrew@omg.org Subject: Re: Urgent issue 3015 > I noticed that the IDL in ptc/98-12-07 does not quite match the > resolution adopted by the core RTF. The difference is that 98-12-07 > contains lines such as > #pragma version InterfaceDef 2.3 > and the adopted IDL does not. > Yes, we need to figure out what to do with those version pragmas. The problem as usual is convoluted. InterfaceDef derives among other things, from Container, which has changed between 2.2 and 2.3 by virtue of the addition of ValueDef creation operation etc., hence Container is legitimately of a new version, which rightfully should have been done through derivation etc., but Simon and others didn't want to do that because that was too much change. Now then, if Container is versioned then InterfaceDef which is derived from that needs to be versioned too. However, I understand the issue that Simon is raising. The consistent across the board approach to this in the context of IFR is to remove all version pragmas and depend on the appropriate raising of BAD_OPERATION exception when a newer version client calls an older version server, something that already should work. I think it is worth documenting this decision adequately so that we do not go into the "IFR is not adequately versioned" discussion again. > I am hoping that this is an editorial oversight and can be corrected > as such. Leaving these pragmas in the IDL is disastrous because it creates > the same problem that 3015 was intended to solve, namely backwards > incompatibility with the CORBA 2.2 IR. > See above. Actaully the resolution of 3015 was incomplete in this respect. We did not say anything about what is to be done with the version pragmas in the rest of IFR. So blindly putting it in effect would cause InterfaceDef:1.0 to be derived from Container:2.3, not a good thing. I think to be consistent we need to remove the version pragmas from at least everything that is involved in the declaration of InterfaceDef. The easiest way to do this would be to remove all version pragmas from IFR. If the collective feeling is leaning towards this, I will write up an alternate resolution to 3015, adding this to the rest of the resolution and then we will put it to vote say starting tomorrow, for a quick turnaround 3 day vote. Comments? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 24 Jan 2000 13:10:31 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Vijaykumar Natarajan , jis@fpk.hp.com, orb_revision@omg.org, butek@us.ibm.com, andrew@omg.org Subject: Re: Urgent issue 3015 References: <388B48B1.4DDE273E@hursley.ibm.com> <388CA336.17CB5D86@fpk.hp.com> <388CABAD.9AEA4CBD@inprise.com> <388CB6B3.4E4C5F9F@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: a;i!!lZf!!mJG!!0+^!! Not at all, I wasn't suggesting we drop InterfaceDescription_2_3. remember, it was in the CORBA module, and I was talking about changes to InterfaceDef. InterfaceDescription_2_3 will continue to exist in the CORBA module. I was merely focussing on the stuff contained in the the InterfaceDef_2_3 interface. This brings up an interesting issue. describe(), the operation on contained, typically returns the Description struct in an any. For 2.3 IR, that would be the InterfaceDescription_2_3 while for 2.0 IR, it will be the InterfaceDescription struct. Inheritance or otherwise, there will be no way for the 2.3 server to know which kind the client is expecting. And of course, the 2.0 client will barf at a InterfaceDescription_2_3 w/ either strategies(Inheritance or otherwise, unless the IFR implements 2 servants to handle each, which is hardly elegant). I would suggest adding a describe_2_3() operation to Contained (which will return the 2.3 types) and have describe always return the 2.0 compatible versions, so 2.3 clients will call describe_2_3 and 2.0 clients calling describe will always get what they expect. Vijay Simon Nash wrote: > Vijay, > The only problem with this is that InterfaceDescription_2_3 has gone > because > there is no operation to obtain it. So we have lost the > correspondence between > InterfaceDescription/FullInterfaceDescription and the same pair of > 2.3 versioned > equivalents. > > Simon > > Vijaykumar Natarajan wrote: > > > > Hi all, > > > > > However, I understand the issue that Simon is raising. The > consistent across the > > > board approach to this in the context of IFR is to remove all > version pragmas > > > and depend on the appropriate raising of BAD_OPERATION exception > when a newer > > > version client calls an older version server, something that > already should > > > work. > > > > If we are going to rely on BAD_OPERATION for Container, why do we > have to complicate > > things for InterfaceDef. > > Why don't we add the following: > > // read/write interface > > attribute boolean is_abstract; > > // read interface > > struct FullInterfaceDescription_2_3 { > > Identifier name; > > RepositoryId id; > > RepositoryId defined_in; > > VersionSpec version; > > OpDescriptionSeq operations; > > AttrDescriptionSeq attributes; > > RepositoryIdSeq base_interfaces; > > TypeCode type; > > boolean is_abstract; > > }; > > FullInterfaceDescription_2_3 describe_interface_2_3(); > > to the current InterfaceDef. Since we are adding new attributes > and methods, they > > will exhibit the same behavior as > > the ValueDef creation operations. The addition of types should > have no effect on > > backward compatibility. And of course, remove all the pragmas. > > > > Vijay > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: jis@fpk.hp.com cc: orb_revision@omg.org, andrew@omg.org Message-ID: <85256870.0070D1ED.00@d54mta08.raleigh.ibm.com> Date: Mon, 24 Jan 2000 14:26:22 -0600 Subject: Re: Urgent issue 3015 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: `E0!!OJH!!d#Ce9968!! Jishnu, Just to make a bit more noise, the collective feeling, at least at IBM, is definitely leaning towards removing all version pragmas from IFR. That's what I'd vote for. Russell Butek butek@us.ibm.com Jishnu Mukerji on 01/24/2000 01:08:38 PM Please respond to jis@fpk.hp.com To: Simon Nash cc: orb_revision@omg.org, Russell Butek/Austin/IBM@IBMUS, andrew@omg.org Subject: Re: Urgent issue 3015 > I noticed that the IDL in ptc/98-12-07 does not quite match the > resolution adopted by the core RTF. The difference is that 98-12-07 > contains lines such as > #pragma version InterfaceDef 2.3 > and the adopted IDL does not. > Yes, we need to figure out what to do with those version pragmas. The problem as usual is convoluted. InterfaceDef derives among other things, from Container, which has changed between 2.2 and 2.3 by virtue of the addition of ValueDef creation operation etc., hence Container is legitimately of a new version, which rightfully should have been done through derivation etc., but Simon and others didn't want to do that because that was too much change. Now then, if Container is versioned then InterfaceDef which is derived from that needs to be versioned too. However, I understand the issue that Simon is raising. The consistent across the board approach to this in the context of IFR is to remove all version pragmas and depend on the appropriate raising of BAD_OPERATION exception when a newer version client calls an older version server, something that already should work. I think it is worth documenting this decision adequately so that we do not go into the "IFR is not adequately versioned" discussion again. > I am hoping that this is an editorial oversight and can be corrected > as such. Leaving these pragmas in the IDL is disastrous because it creates > the same problem that 3015 was intended to solve, namely backwards > incompatibility with the CORBA 2.2 IR. > See above. Actaully the resolution of 3015 was incomplete in this respect. We did not say anything about what is to be done with the version pragmas in the rest of IFR. So blindly putting it in effect would cause InterfaceDef:1.0 to be derived from Container:2.3, not a good thing. I think to be consistent we need to remove the version pragmas from at least everything that is involved in the declaration of InterfaceDef. The easiest way to do this would be to remove all version pragmas from IFR. If the collective feeling is leaning towards this, I will write up an alternate resolution to 3015, adding this to the rest of the resolution and then we will put it to vote say starting tomorrow, for a quick turnaround 3 day vote. Comments? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 24 Jan 2000 13:10:31 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Vijaykumar Natarajan , jis@fpk.hp.com, orb_revision@omg.org, butek@us.ibm.com, andrew@omg.org Subject: Re: Urgent issue 3015 References: <388B48B1.4DDE273E@hursley.ibm.com> <388CA336.17CB5D86@fpk.hp.com> <388CABAD.9AEA4CBD@inprise.com> <388CB6B3.4E4C5F9F@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: a;i!!lZf!!mJG!!0+^!! Not at all, I wasn't suggesting we drop InterfaceDescription_2_3. remember, it was in the CORBA module, and I was talking about changes to InterfaceDef. InterfaceDescription_2_3 will continue to exist in the CORBA module. I was merely focussing on the stuff contained in the the InterfaceDef_2_3 interface. This brings up an interesting issue. describe(), the operation on contained, typically returns the Description struct in an any. For 2.3 IR, that would be the InterfaceDescription_2_3 while for 2.0 IR, it will be the InterfaceDescription struct. Inheritance or otherwise, there will be no way for the 2.3 server to know which kind the client is expecting. And of course, the 2.0 client will barf at a InterfaceDescription_2_3 w/ either strategies(Inheritance or otherwise, unless the IFR implements 2 servants to handle each, which is hardly elegant). I would suggest adding a describe_2_3() operation to Contained (which will return the 2.3 types) and have describe always return the 2.0 compatible versions, so 2.3 clients will call describe_2_3 and 2.0 clients calling describe will always get what they expect. Vijay Simon Nash wrote: > Vijay, > The only problem with this is that InterfaceDescription_2_3 has gone > because > there is no operation to obtain it. So we have lost the > correspondence between > InterfaceDescription/FullInterfaceDescription and the same pair of > 2.3 versioned > equivalents. > > Simon > > Vijaykumar Natarajan wrote: > > > > Hi all, > > > > > However, I understand the issue that Simon is raising. The > consistent across the > > > board approach to this in the context of IFR is to remove all > version pragmas > > > and depend on the appropriate raising of BAD_OPERATION exception > when a newer > > > version client calls an older version server, something that > already should > > > work. > > > > If we are going to rely on BAD_OPERATION for Container, why do we > have to complicate > > things for InterfaceDef. > > Why don't we add the following: > > // read/write interface > > attribute boolean is_abstract; > > // read interface > > struct FullInterfaceDescription_2_3 { > > Identifier name; > > RepositoryId id; > > RepositoryId defined_in; > > VersionSpec version; > > OpDescriptionSeq operations; > > AttrDescriptionSeq attributes; > > RepositoryIdSeq base_interfaces; > > TypeCode type; > > boolean is_abstract; > > }; > > FullInterfaceDescription_2_3 describe_interface_2_3(); > > to the current InterfaceDef. Since we are adding new attributes > and methods, they > > will exhibit the same behavior as > > the ValueDef creation operations. The addition of types should > have no effect on > > backward compatibility. And of course, remove all the pragmas. > > > > Vijay > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Paul Kyzivat To: orb_revision@omg.org Cc: andrew@omg.org Subject: RE: Urgent issue 3015 Date: Mon, 24 Jan 2000 17:01:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: R#nd9Oea!!Do=e9U,6!! I see the logic in what you propose, and I don't have a better solution to offer. BUT, this is damned disappointing. Our first attempt at addressing the versioning problem has gone down in flames! I fear that future attempts will meet with a similar degree of success. As an aside - in the future, I hope we can come up with better name than foo_M_N for an extension to foo. It won't take very long before people don't care and don't want to remember what version happened to incorporate a particular wart. At that point, if not sooner, they will be cursing us. (For example, something like AbstractableInterfaceDef would have some more mnemonic value than InterfaceDef_2_3. I realize this is still ugly, but not quite as ugly.) Paul > -----Original Message----- > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > See above. Actaully the resolution of 3015 was incomplete in > this respect. We > did not say anything about what is to be done with the > version pragmas in the > rest of IFR. So blindly putting it in effect would cause > InterfaceDef:1.0 to be > derived from Container:2.3, not a good thing. I think to be > consistent we need > to remove the version pragmas from at least everything that > is involved in the > declaration of InterfaceDef. The easiest way to do this would > be to remove all > version pragmas from IFR. If the collective feeling is > leaning towards this, I > will write up an alternate resolution to 3015, adding this to > the rest of the > resolution and then we will put it to vote say starting > tomorrow, for a quick > turnaround 3 day vote. > > Comments? > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > > Sender: jbiggar@corvette.floorboard.com Message-ID: <388CC3DD.4A70B3E3@floorboard.com> Date: Mon, 24 Jan 2000 13:27:57 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: jis@fpk.hp.com, Simon Nash , > orb_revision@omg.org, butek@us.ibm.com, andrew@omg.org Subject: Re: Urgent issue 3015 References: <388B48B1.4DDE273E@hursley.ibm.com> <388CA336.17CB5D86@fpk.hp.com> <388CABAD.9AEA4CBD@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: K?G!!jOVd9\m9!!kGMe9 Vijaykumar Natarajan wrote: > If we are going to rely on BAD_OPERATION for Container, why do we have to > complicate things for InterfaceDef. Good question! If we are going to accept that we are adding new operations without updating the version in one place, then let's just do it everywhere and get rid of the ugly InterfaceDef_2_3 derivation. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: mark@192.168.1.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 13:42:22 -0800 To: Steve Vinoski , Andrew Watson From: Mark Spruiell Subject: Re: Issue 3015 classified as Urgent Cc: orb_revision@omg.org, Linda Heaton In-Reply-To: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: KjI!!SS(e94!-e9#@~e9 Hi Steve, At 12:31 PM 1/24/00 , Steve Vinoski wrote: >[...] >IMO we need to get this problem resolved as best as we possibly can. I >believe the resolution proposed below to be superior to the resolution >recently adopted by the Core RTF. Now that this issue is urgent, we have >the ability to consider it fully one more time before adopting anything in >haste. Please review the following and submit your comments. This proposal will clean things up significantly. One comment: this proposal would render obsolete the first three actions of the resolution for orb_revision issue 2156: http://www.omg.org/pub/orbrev/drafts/orb_revision_2k_resolved.html#Issue2156 Actions 4 & 5 are still relevant, but the text for 5 would need to be fixed. Take care, Mark -- Mark E. Spruiell Object Oriented Concepts, Inc. mes@ooc.com * http://www.ooc.com * 1-978-439-9285 x 247 Date: Mon, 24 Jan 2000 17:20:17 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan Cc: Simon Nash , orb_revision@omg.org, butek@us.ibm.com, andrew@omg.org Subject: Re: Urgent issue 3015 References: <388B48B1.4DDE273E@hursley.ibm.com> <388CA336.17CB5D86@fpk.hp.com> <388CABAD.9AEA4CBD@inprise.com> <388CB6B3.4E4C5F9F@hursley.ibm.com> <388CBFC7.4E326A8@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [4#!!TW>e9c]ld9U!2e9 Vijaykumar Natarajan wrote: > Not at all, I wasn't suggesting we drop InterfaceDescription_2_3. remember, it was in the > CORBA module, and I was talking about changes to InterfaceDef. InterfaceDescription_2_3 > will continue to exist in the CORBA module. I was merely focussing on the stuff contained > in the the InterfaceDef_2_3 interface. > > This brings up an interesting issue. describe(), the operation on contained, typically > returns the Description struct in an any.For 2.3 IR, that would be the > InterfaceDescription_2_3 while for 2.0 IR, it will be the InterfaceDescription struct. > Inheritance or otherwise, there will be no way for the 2.3 server to know which kind the > client is expecting. Let me try to understand this. The scenario is as follows: A 2.2 client does an Object::get_interface and is returned an InterfaceDef_2_3 objref by 2.3 IR, . Now it is going to invoke various operations on it. Since it is a 2.2 client, it clearly does not know about narrowing the InterfaceDef that it gets to InterfaceDef_2_3, nor does it know about the describe_interface_2_3 operation. But it does know about the describe operation, and it invokes that. Now the question is what does the 2.3 IFR return. What if we specify that the 2.3 IFR always returns an InterfaceDescription in response to describe, and simply do away with InterfaceDescription_2_3? Isn't that a cleaner solution with minimal loss of functionality for this urgent resolution, than going off and twiddling around with Contained? [Anyway read on below to see completion of my chain of thoughts]. > And of course, the 2.0 client will barf at a InterfaceDescription_2_3 > w/ either strategies(Inheritance or otherwise, unless the IFR implements 2 servants to > handle each, which is hardly elegant). I would suggest adding a describe_2_3() operation > to Contained (which will return the 2.3 types) and have describe always return the 2.0 > compatible versions, so 2.3 clients will call describe_2_3 and 2.0 clients calling > describe will always get what they expect. Now considering the other combination, if a 2.3 client invokes get_interface on an Object and gets an objref to an InterfaceDef from a 2.2 IFR, if the derivation approach is used then it will fail to narrow to InterfaceDef_2_3 and hence will never be able to invoke any of the 2.3 operations. When it invokes describe it will get InterfaceDescription if we specify that that is what is always returned by describe. If the other approach is used then depending on whether it was a 2.2 IFR or a 2.3 IFR, it will get back from describe either an InterfaceDescription or an InterfaceDescription_2_3, and they go about being confused about which one it got too. On the whole I think it is a bad idea to say that InterfaceDef_2_3 describe should return InterfaceDescription_2_3. I don't think it is workable. I think this is a legitimate bug in the resolution for 3015 that needs fixing. The fix is to replace the paragraph in section 10.5.24.1 that reads: "The inherited describe operation for an InterfaceDef_2_3 returns an InterfaceDescription_2_3. " and replace it by: "The inherited describe operation for an InterfaceDef_2_3 returns an InterfaceDescription." Furthermore, if we must have an InterfaceDescription_2_3, I would recommend that instead of polluting Contained with an operation that is needed just for this InterfaceDef twiddle, we add the operation "describe_2_3" to InterfaceDef_2_3 to return InterfaceDescription_2_3. Alternatively we could simply bag InterfaceDescription_2_3 with very minimal, if any, loss of functionality. Comments? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 24 Jan 2000 17:36:55 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Cc: Steve Vinoski , Andrew Watson Subject: Re: Issue 3015 classified as Urgent References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: KD_d9/XEe9+5Ke9)Z>!! > At 06:59 PM 1/18/00 -0500, Andrew Watson wrote: > >Good Evening, > > > >At Jishnu's request I am classifying Issue 3015 (IFR backward > compatibility > >fix) as Urgent and assigning it to the CORBA core RTF. This is > being done > >so that it can be incorporated into CORBA 2.3.x as soon as > possible. > > > >The default resolution for this issue is attached. This is > *exactly* the > >resolution that was recently passed by the old core RTF, so > classifying it > >as urgent is merely a pro-forma exercise to get it into the next > minor > >revision to CORBA 2.3.x. > > Having checked with Andrew and Jishnu about the legitimacy of > proposing an > alternative resolution to this urgent issue, and having received a > positive > reply from both, I would like the Core RTF to consider the > following. > > A proper resolution to 3015 should recognize that because Abstract > Interfaces are a distinct type in IDL, they should be their own type > in the > IFR as well. This distinction has already been addressed in > TypeCodes with > create_abstract_interface_tc and tk_abstract_interface. Because the > behaviors of interfaces and abstract interfaces are very different, > this > should also be stressed in the IFR. > > The Interface_2_3 solution is messy, and if adopted could create > even more > problems down the road for the IFR and for Components (if they > choose to > use similar tactics for versioning other things). What happens when > "local" interfaces are adopted? Are we going to add an > Interface_3_0 to > the CORBA spec? What about versions after 3.0? > > IMO we need to get this problem resolved as best as we possibly > can. I > believe the resolution proposed below to be superior to the > resolution > recently adopted by the Core RTF. Now that this issue is urgent, we > have > the ability to consider it fully one more time before adopting > anything in > haste. Please review the following and submit your comments. > Personally, I really like that. It is certainly much cleaner and more easily understandable than anything else that I have seen so far. Very nice and clean separation of pre-2.3 and 2.3 features. I will certainly use that approach for local interfaces in the CCM IFR revision. As for what is to be done for abstract interfaces right now let the discussions continue. I will check in Wednesday night to see where the discussions have led to and create a vote reflecting alternatives, and send the vote out Thursday morning, with votes due by the following Monday (Jan 31). I will place the alternaitve resolutions on the vote in the form of an exclusive or vote. The resolution that gets the most YES votes will win. If no resolution gets more YES votes than NO votes then the current resolution to 3015 will stand. So far, I have the following alternatives: (1) The original 3015 resolution + remove all version pragma (2) 3015 resolution with first set of Vijay changes and version pragmas removed. (3) 3015 resolution with second set of Vijay changes (add describe_2_3 to Contained) and version pragmas removed. (4) Steve Vinoski propsal with complete separation of AbstractInterfaceDef. and version pragmas removed. Sound like a plan? Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 24 Jan 2000 15:23:56 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: orb_revision@omg.org, Steve Vinoski , Andrew Watson Subject: Re: Issue 3015 classified as Urgent References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> <388CD407.A921628D@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: PVW!!k7l!!K3-e9g%gd9 > Just to make sure that everybody is clear on the set of "Vijay changes", It is the collapsing of InterfaceDef_2_3 into InterfaceDef and adding all the stuff that was in InterfaceDef_2_3 to InterfaceDef. Option 3, addresses the issue of describe() in addition to the previous changes which will have to be addressed irrespective of the options chosen (except for option 4, of course). If we don't go w/ this option, and we choose 2 or 1, we will have to clarify the behavior of describe(). One comment on option 4 is w/ respect to abstract valuetypes. If we do this for interfaces, shouldn't we also do it for value types? Just a doubt. Personally, I am happy w/ not touching abstract valuetypes as it is not such a different beast from valuetypes. Thanks, Vijay > Personally, I really like that. It is certainly much cleaner and more easily > understandable than anything else that I have seen so far. Very nice and clean > separation of pre-2.3 and 2.3 features. I will certainly use that approach for > local interfaces in the CCM IFR revision. As for what is to be done for abstract > interfaces right now let the discussions continue. > > I will check in Wednesday night to see where the discussions have led to and > create a vote reflecting alternatives, and send the vote out Thursday morning, > with votes due by the following Monday (Jan 31). I will place the alternaitve > resolutions on the vote in the form of an exclusive or vote. The resolution that > gets the most YES votes will win. If no resolution gets more YES votes than NO > votes then the current resolution to 3015 will stand. > > So far, I have the following alternatives: > > (1) The original 3015 resolution + remove all version pragma > > (2) 3015 resolution with first set of Vijay changes and version pragmas removed. > > > (3) 3015 resolution with second set of Vijay changes (add describe_2_3 to > Contained) and version pragmas removed. > > (4) Steve Vinoski propsal with complete separation of AbstractInterfaceDef. and > version pragmas removed. > > Sound like a plan? > > Thanks, > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 24 Jan 2000 18:20:30 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan Cc: Simon Nash , orb_revision@omg.org, butek@us.ibm.com, andrew@omg.org Subject: Re: Urgent issue 3015 References: <388B48B1.4DDE273E@hursley.ibm.com> <388CA336.17CB5D86@fpk.hp.com> <388CABAD.9AEA4CBD@inprise.com> <388CB6B3.4E4C5F9F@hursley.ibm.com> <388CBFC7.4E326A8@inprise.com> <388CD020.B75E4999@fpk.hp.com> <388CD4F1.4DD4C368@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: >#d!!8K$e9NH]!!e2%!! Vijaykumar Natarajan wrote: > Hi Jishnu, > > Looks like you misread my comments. I wasn't suggesting that 2.3 InterfaceDef describe (be it the > inherited version or just the former) return a InterfaceDescription_2_3. I was saying that per the > current proposal, that's what it appears to return, which as you have reiterated, is a problem for > pre 2.3 clients. Yes, it certainly does, and that is a problem as we appear to agree. > If we add describe_2_3 to anything other than contained we have the foll. problem: > > For clients that use describe in a generic way however, they may use RepositoryIds to get to > contained objects and use repositoryIds in them to get to other contained object and may never > require to narrow to the specific Def object. if we add the describe_2_3 to InterfaceDef, > then they would be forced to do this. If however, we fixed contained to have this operation, then > new clients could again generically deal with containeds and their ContainedDescriptions by only > calling describe_2_3, which will do 2.3 specific stuff for the types that have changed but default > to what describe does for types that haven't, w/o having to special case Interfaces. Yes, but my concern is that the next time we add some more crud into InterfaceDef we will land up adding describe_4_5 or whatever to contained and so on. On the whole this leads me to believe that the path that we are taking is realtively broken. > Independent of the above, I agree that removing InterfaceDef_2_3 altogether is a better approach > (of course, in light of Steve's proposal, we may choose to use an entirely different type, in > which case, this discussion is moot). Correct. The way I look at Steve's proposal is to view it as if InterfaceDef_2_3 were renamed AbstractInterfaceDef, and AbstractInterfaceDef derived from InterfaceDef as does InterfaceDef_2_3, and had exactly the same operations as InterfaceDef except that its "abstractness" is encoded in its type. That is what makes it cleaner I think. The fundamental problem that we are dancing around is how to add an additional peice of data to the "*Description* struct, and still make it work compatibly. Steve's proposal eliminates the need to add the extra piece of data to the struct by encoding the same information in the type of the *Def. I harbored considerable concern initially about how difficult it will be to incorporate Steve's proposal in already deployed systems. Upon further consideration it appears to me that it should be no more diffuclt than incorporating the current resolution to 3015, because purely in terms of IDL change etc. they are very similar, so that concern is much reduced now, after seeing the full proposal. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 24 Jan 2000 14:40:49 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: Vijaykumar Natarajan , Simon Nash , orb_revision@omg.org, butek@us.ibm.com, andrew@omg.org Subject: Re: Urgent issue 3015 References: <388B48B1.4DDE273E@hursley.ibm.com> <388CA336.17CB5D86@fpk.hp.com> <388CABAD.9AEA4CBD@inprise.com> <388CB6B3.4E4C5F9F@hursley.ibm.com> <388CBFC7.4E326A8@inprise.com> <388CD020.B75E4999@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _Wjd9b31!!B[Qd9DP(e9 Hi Jishnu, Looks like you misread my comments. I wasn't suggesting that 2.3 InterfaceDef describe (be it the inherited version or just the former) return a InterfaceDescription_2_3. I was saying that per the current proposal, that's what it appears to return, which as you have reiterated, is a problem for pre 2.3 clients. If we add describe_2_3 to anything other than contained we have the foll. problem: For clients that use describe in a generic way however, they may use RepositoryIds to get to contained objects and use repositoryIds in them to get to other contained object and may never require to narrow to the specific Def object. if we add the describe_2_3 to InterfaceDef, then they would be forced to do this. If however, we fixed contained to have this operation, then new clients could again generically deal with containeds and their ContainedDescriptions by only calling describe_2_3, which will do 2.3 specific stuff for the types that have changed but default to what describe does for types that haven't, w/o having to special case Interfaces. Independent of the above, I agree that removing InterfaceDef_2_3 altogether is a better approach (of course, in light of Steve's proposal, we may choose to use an entirely different type, in which case, this discussion is moot). Vijay Jishnu Mukerji wrote: > Vijaykumar Natarajan wrote: > > > Not at all, I wasn't suggesting we drop InterfaceDescription_2_3. remember, it was in the > > CORBA module, and I was talking about changes to InterfaceDef. InterfaceDescription_2_3 > > will continue to exist in the CORBA module. I was merely focussing on the stuff contained > > in the the InterfaceDef_2_3 interface. > > > > This brings up an interesting issue. describe(), the operation on contained, typically > > returns the Description struct in an any.For 2.3 IR, that would be the > > > InterfaceDescription_2_3 while for 2.0 IR, it will be the InterfaceDescription struct. > > Inheritance or otherwise, there will be no way for the 2.3 server to know which kind the > > client is expecting. > > Let me try to understand this. The scenario is as follows: > > A 2.2 client does an Object::get_interface and is returned an InterfaceDef_2_3 objref by 2.3 > IR, . Now it is going to invoke various operations on it. Since it is a 2.2 client, it clearly > does not know about narrowing the InterfaceDef that it gets to InterfaceDef_2_3, nor does it > know about the describe_interface_2_3 operation. But it does know about the describe > operation, and it invokes that. Now the question is what does the 2.3 IFR return. What if we > specify that the 2.3 IFR always returns an InterfaceDescription in response to describe, and > simply do away with InterfaceDescription_2_3? Isn't that a cleaner solution with minimal loss > of functionality for this urgent resolution, than going off and twiddling around with > Contained? [Anyway read on below to see completion of my chain of thoughts]. > > > And of course, the 2.0 client will barf at a InterfaceDescription_2_3 > > w/ either strategies(Inheritance or otherwise, unless the IFR implements 2 servants to > > handle each, which is hardly elegant). I would suggest adding a describe_2_3() operation > > to Contained (which will return the 2.3 types) and have describe always return the 2.0 > > compatible versions, so 2.3 clients will call describe_2_3 and 2.0 clients calling > > describe will always get what they expect. > > Now considering the other combination, if a 2.3 client invokes get_interface on an Object and > gets an objref to an InterfaceDef from a 2.2 IFR, if the derivation approach is used then it > will fail to narrow to InterfaceDef_2_3 and hence will never be able to invoke any of the 2.3 > operations. When it invokes describe it will get InterfaceDescription if we specify that that > is what is always returned by describe. If the other approach is used then depending on > whether it was a 2.2 IFR or a 2.3 IFR, it will get back from describe either an > InterfaceDescription or an InterfaceDescription_2_3, and they go about being confused about > which one it got too. > > On the whole I think it is a bad idea to say that InterfaceDef_2_3 describe should return > InterfaceDescription_2_3. I don't think it is workable. I think this is a legitimate bug in > the resolution for 3015 that needs fixing. The fix is to replace the paragraph in section > 10.5.24.1 that reads: > > "The inherited describe operation for an InterfaceDef_2_3 returns an InterfaceDescription_2_3. > " > > and replace it by: > > "The inherited describe operation for an InterfaceDef_2_3 returns an InterfaceDescription." > > Furthermore, if we must have an InterfaceDescription_2_3, I would recommend that instead of > polluting Contained with an operation that is needed just for this InterfaceDef twiddle, we > add the operation "describe_2_3" to InterfaceDef_2_3 to return InterfaceDescription_2_3. > Alternatively we could simply bag InterfaceDescription_2_3 with very minimal, if any, loss of > functionality. > > Comments? > > Jishnu. > > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 24 Jan 2000 23:58:49 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Steve Vinoski CC: Andrew Watson , orb_revision@omg.org, Linda Heaton Subject: Re: Issue 3015 classified as Urgent References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -?m!!Y>gd9L^L!!bg2!! Steve. Steve Vinoski wrote: > > ...cut... > > IMO we need to get this problem resolved as best as we possibly can. I > believe the resolution proposed below to be superior to the resolution > recently adopted by the Core RTF. Now that this issue is urgent, we have > the ability to consider it fully one more time before adopting anything in > haste. Please review the following and submit your comments. > Steve, I like this proposal. It is a lot cleaner than the xxx_2_3 mess. Only one thing bothers me, and that is the derivation of AbstractInterfaceDef from InterfaceDef. According to OO theory this implies that an abstract interface is a more specific subtype of a regular interface, which isn't true. A more accurate representation of the IDL type hierarchy would be to derive both AbstractInterfaceDef and InterfaceDef from the base Container, Contained, and IDLType interfaces. This approach would require copying the operations of InterfaceDef into AbstractInterfaceDef. That's the downside, but I think this is (just) preferable to subverting the correct type hierarchy. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 25 Jan 2000 09:08:04 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: orb_revision@omg.org, andrew@omg.org Subject: RE: Urgent issue 3015 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA9140304@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Y7C!!;!5e9R~[d9SIG!! On Mon, 24 Jan 2000, Paul Kyzivat wrote: > As an aside - in the future, I hope we can come up with better name than > foo_M_N for an extension to foo. It won't take very long before people don't > care and don't want to remember what version happened to incorporate a > particular wart. At that point, if not sooner, they will be cursing us. (For > example, something like AbstractableInterfaceDef would have some more > mnemonic value than InterfaceDef_2_3. I realize this is still ugly, but not > quite as ugly.) That particular problem could be addressed by adding a more readable typedef. But I agree with your sentiment -- the names aren't exactly mnemonic or appealing... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <388CE797.2C05E46E@floorboard.com> Date: Mon, 24 Jan 2000 16:00:23 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: orb_revision@omg.org, Steve Vinoski , Andrew Watson Subject: Re: Issue 3015 classified as Urgent References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> <388CD407.A921628D@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +m2e9joSd9>;Ee9>g3e9 Jishnu Mukerji wrote: > So far, I have the following alternatives: > > (1) The original 3015 resolution + remove all version pragma > > (2) 3015 resolution with first set of Vijay changes and version > pragmas removed. > > (3) 3015 resolution with second set of Vijay changes (add > describe_2_3 to > Contained) and version pragmas removed. > > (4) Steve Vinoski propsal with complete separation of > AbstractInterfaceDef. and > version pragmas removed. > > Sound like a plan? To show more support for Steve's proposal (#4), I thought of two issues and realized they are handled elegantly by his proposal. 1. Interfaces can inherit from abstract interfaces. At first blush this might cause problem with the definition of InterfaceDef, since the base_interfaces attribute takes an InterfaceDefSeq. But this isn't a problem, since in Steve's proposal, AbstractInterfaceDef inherits from InterfaceDef. 2. What happens when a CORBA 2.2 IFR client walks the inheritence heirarchy and runs into an abstract interface? Again, since AbstractInterfaceDef inherits from InterfaceDef, it will get back stuff it understands. The only minor problem is that it will assume that the abstract interface is just a normal interface. Can anyone see any bad failure scenarios with this? In a nutshell, Steve's proposal removes the is_abstract attribute and replaces it with inheritence. To make the equivalent query, just call: Object::is_a("IDL:omg.org/CORBA/AbstractInterfaceDef:1.0") -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@corvette.floorboard.com Message-ID: <388CCDA6.21BC3A2@floorboard.com> Date: Mon, 24 Jan 2000 14:09:42 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Steve Vinoski CC: Andrew Watson , orb_revision@omg.org, Linda Heaton Subject: Re: Issue 3015 classified as Urgent References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0&Ke9\j[!!ZlBe9gi9!! Steve Vinoski wrote: > A proper resolution to 3015 should recognize that because Abstract > Interfaces are a distinct type in IDL, they should be their own type > in the > IFR as well. This distinction has already been addressed in > TypeCodes with > create_abstract_interface_tc and tk_abstract_interface. Because the > behaviors of interfaces and abstract interfaces are very different, > this > should also be stressed in the IFR. I like this proposal. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 24 Jan 2000 16:50:09 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Steve Vinoski , Andrew Watson , orb_revision@omg.org, Linda Heaton Subject: Re: Issue 3015 classified as Urgent References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> <388CE739.E05A06CC@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [W[d9$dD!!nkZ!!L"Rd9 I wrote this mail a few minutes ago, but decided not to send it as it was drastic. Now in light of this comment, I would like to be a little more brave and suggest the following: interface MethodsAndAttributesContainer /*For want of a better name*/ { AttributeDef create_attribute(...) ...; OperationDef create_operation(...)...; }; Which can be extended by InterfaceDef, AbstractInterfaceDef, LocalInterfaceDef and hey, even ValueDef. thanks, Vijay Simon Nash wrote: > Steve. > > Steve Vinoski wrote: > > > > ...cut... > > > > IMO we need to get this problem resolved as best as we possibly can. I > > believe the resolution proposed below to be superior to the resolution > > recently adopted by the Core RTF. Now that this issue is urgent, we have > > the ability to consider it fully one more time before adopting anything in > > haste. Please review the following and submit your comments. > > > Steve, > I like this proposal. It is a lot cleaner than the xxx_2_3 mess. Only > one thing bothers me, and that is the derivation of AbstractInterfaceDef > from InterfaceDef. According to OO theory this implies that an abstract > interface is a more specific subtype of a regular interface, which isn't > true. A more accurate representation of the IDL type hierarchy would be to > derive both AbstractInterfaceDef and InterfaceDef from the base Container, > Contained, and IDLType interfaces. > > This approach would require copying the operations of InterfaceDef into > AbstractInterfaceDef. That's the downside, but I think this is (just) > preferable to subverting the correct type hierarchy. > > Simon > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jbiggar@corvette.floorboard.com Message-ID: <388CFA0E.F6C8FD36@floorboard.com> Date: Mon, 24 Jan 2000 17:19:10 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Steve Vinoski , Andrew Watson , orb_revision@omg.org, Linda Heaton Subject: Re: Issue 3015 classified as Urgent References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> <388CE739.E05A06CC@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: J:#e9$'Ae9<@E!!R`8!! Simon Nash wrote: > I like this proposal. It is a lot cleaner than the xxx_2_3 mess. > Only > one thing bothers me, and that is the derivation of > AbstractInterfaceDef > from InterfaceDef. According to OO theory this implies that an > abstract > interface is a more specific subtype of a regular interface, which > isn't > true. A more accurate representation of the IDL type hierarchy > would be to > derive both AbstractInterfaceDef and InterfaceDef from the base > Container, > Contained, and IDLType interfaces. > > This approach would require copying the operations of InterfaceDef > into > AbstractInterfaceDef. That's the downside, but I think this is > (just) > preferable to subverting the correct type hierarchy. Simon, this doesn't work, since it breaks the ability of an InterfaceDef to be inherited from an AbstractInterfaceDef. So even though I agree with you that your method would be cleaner OO-wise, Steve's method doesn't have this fatal flaw. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 25 Jan 2000 09:00:46 -0500 To: Simon Nash From: Steve Vinoski Subject: Re: Issue 3015 classified as Urgent Cc: Andrew Watson , orb_revision@omg.org, Linda Heaton In-Reply-To: <388CFA0E.F6C8FD36@floorboard.com> References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> <388CE739.E05A06CC@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: kOpd9$SL!!^U\d9T_Me9 At 05:19 PM 1/24/00 -0800, Jonathan Biggar wrote: >Simon Nash wrote: >> I like this proposal. It is a lot cleaner than the xxx_2_3 mess. Only >> one thing bothers me, and that is the derivation of AbstractInterfaceDef >> from InterfaceDef. According to OO theory this implies that an abstract >> interface is a more specific subtype of a regular interface, which isn't >> true. A more accurate representation of the IDL type hierarchy would be to >> derive both AbstractInterfaceDef and InterfaceDef from the base Container, >> Contained, and IDLType interfaces. >> >> This approach would require copying the operations of InterfaceDef into >> AbstractInterfaceDef. That's the downside, but I think this is (just) >> preferable to subverting the correct type hierarchy. > >Simon, this doesn't work, since it breaks the ability of an InterfaceDef >to be inherited from an AbstractInterfaceDef. So even though I agree >with you that your method would be cleaner OO-wise, Steve's method >doesn't have this fatal flaw. Jon is precisely right. When you call create_interface: InterfaceDef create_interface( name, id, version, InterfaceDefSeq base_interfaces ); the base_interfaces argument must be able to contain regular or abstract interfaces. You could fix this by taking everything out of InterfaceDef, putting it into AbstractInterfaceDef, and then deriving InterfaceDef from AbstractInterfaceDef, but to me that change seems too drastic. --steve From: Paul Kyzivat To: orb_revision@omg.org, Andrew Watson Subject: RE: Issue 3015 classified as Urgent Date: Tue, 25 Jan 2000 16:54:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: [L7e9Un6e9g-m!!o"`!! BTW - I forgot to mention that I support Steve's proposal. From: Paul Kyzivat To: "'orb_revision@omg.org'" Cc: "'Andrew Watson'" Subject: RE: Issue 3015 classified as Urgent Date: Tue, 25 Jan 2000 16:53:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: VJFe9<4B!!G:Ee917?e9 Jishnu, Please, lets not vote on 4 alternatives under the rule that if none gets a majority we go with Andrew's default. That is almost a guarantee of going with Andrew's. At least put the default on equal basis with the others. Better yet, how about a preferential voting scheme like the one we use for AB? (I suppose we legally can't use that for a final vote, but we could use it to select one candidate to vote on.) Paul > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > I will check in Wednesday night to see where the discussions > have led to and > create a vote reflecting alternatives, and send the vote out > Thursday morning, > with votes due by the following Monday (Jan 31). I will place > the alternaitve > resolutions on the vote in the form of an exclusive or vote. > The resolution that > gets the most YES votes will win. If no resolution gets more > YES votes than NO > votes then the current resolution to 3015 will stand. > > So far, I have the following alternatives: > > (1) The original 3015 resolution + remove all version pragma > > (2) 3015 resolution with first set of Vijay changes and > version pragmas removed. > > (3) 3015 resolution with second set of Vijay changes (add > describe_2_3 to > Contained) and version pragmas removed. > > (4) Steve Vinoski propsal with complete separation of > AbstractInterfaceDef. and > version pragmas removed. > > > Sound like a plan? > > Thanks, > > Jishnu. Date: Wed, 26 Jan 2000 11:53:52 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat Cc: orb_revision@omg.org, Steve Vinoski , Andrew Watson Subject: Re: Issue 3015 classified as Urgent References: <9B164B713EE9D211B6DC0090273CEEA9140307@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: SJ/!!l2nd92~e!!cdWd9 Status: RO Paul Kyzivat wrote: > Jishnu, > > Please, lets not vote on 4 alternatives under the rule that if none gets a > majority we go with Andrew's default. That is almost a guarantee of going > with Andrew's. I believe that I sense a general consensus developing around Steve's proposal. So my plan is to put only that proposal up for vote. Unless someone makes a very strong and convincing case for placing anything else on the vote, I will go according to that plan. Later today, i.e. in a couple of hours I will post the cleaned up resolution draft based on Steve's proposal for comments, and tomorrow by 12noon, I will post the vote incorporating any (reasonable:-)) comments that I get back from anyone. > At least put the default on equal basis with the others. > Better yet, how about a preferential voting scheme like the one we > use for > AB? (I suppose we legally can't use that for a final vote, but we > could use > it to select one candidate to vote on.) Don't worry, we won't go there. My veiled threat was only a poor attempt to get people focused on fixing the problem at hand instead of trying to re-design all of IFR.:-) most of us have opinions on how to do the latter, but all of that is mostly out of order as far as the resolution of this narrow issue is concerned. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Wed, 26 Jan 2000 14:15:21 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar Cc: orb_revision@omg.org, Steve Vinoski , Andrew Watson Subject: Re: Issue 3015 classified as Urgent References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> <388CD407.A921628D@fpk.hp.com> <388CE797.2C05E46E@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: A8+!!B7^d9G\~!!NN To show more support for Steve's proposal (#4), I thought of two issues > and realized they are handled elegantly by his proposal. > > 1. Interfaces can inherit from abstract interfaces. At first blush > this might cause problem with the definition of InterfaceDef, since the > base_interfaces attribute takes an InterfaceDefSeq. But this isn't a > problem, since in Steve's proposal, AbstractInterfaceDef inherits from > InterfaceDef. Since Abtract interfaces can only derive from abstract interfaces, I guess we will need to say something about checking that the InterfaceDefs in the base_interface of an AbstractInterfaceDef are actually AbstractInterfaceDefs? > 2. What happens when a CORBA 2.2 IFR client walks the inheritence > heirarchy and runs into an abstract interface? Again, since > AbstractInterfaceDef inherits from InterfaceDef, it will get back > stuff > it understands. The only minor problem is that it will assume that > the > abstract interface is just a normal interface. Can anyone see any > bad > failure scenarios with this? Seems benign to me. Am I missing something? > In a nutshell, Steve's proposal removes the is_abstract attribute and > replaces it with inheritence. To make the equivalent query, just call: > > Object::is_a("IDL:omg.org/CORBA/AbstractInterfaceDef:1.0") Yup. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Wed, 26 Jan 2000 15:18:53 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar , orb_revision@omg.org, Steve Vinoski , Andrew Watson Subject: Re: Issue 3015 classified as Urgent References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> <388CD407.A921628D@fpk.hp.com> <388CE797.2C05E46E@floorboard.com> <388F47C9.CF3376F6@fpk.hp.com> Content-Type: multipart/mixed; boundary="------------DF62A0B4FFFC60DE1BD73466" X-UIDL: RIkd9Nc(e9Pn3!!'!Ee9 Status: RO Dear Core RTF voters and other interested in the urgent resolution of issue 3015 Attached is the complete resolution for 3015 reflecting the Steve Vinoski approach. I have filled in additional detailed text covering areas where AbstractInterfaceDefs are different from InterfaceDefs. I have also added removal of all version pragmas from IFR with a pseudo-justification. I have also covered the case where someone could attemt to set_base_interfaces of an AbstractInterfaceDef with an InterfaceDefSeq that contains an InterfaceDef that is not also an AbstractInterfaceDef. This requires raising a BAD_PARAM exception with a different minor code, which I have also added. Please review and comment quickly so that your comments can be given due consideration before the vote goes out tomorrow (Thursday) afternoon. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Issue 3015: why was is_abstract added to structs in CORBA IR? (orb_revision) Click here for this issue's archive. Nature: Clarification Severity: Summary: I was wondering if anyone can explain the rationale for adding the field 'is_abstract' to the CORBA::InterfaceDescription and CORBA::InterfaceDef::FullInterfaceDescription struct types in the CORBA 2.3 Interface Repository specification. (I do know about abstract interfaces, I am really looking for the rationale for breaking backwards compabitility). Basically, a CORBA 2.3 client using stubs compiled from the latest IDL cannot interoperate using IIOP with the Interface Repository of a pre-CORBA 2.3 ORB, because virtually any client of the IR will want to obtain a FullInterfaceDescription from an InterfaceDef, and a pre-CORBA 2.3 ORB will not marshal the 'is_abstract' field for the description struct, thereby the CORBA 2.3 client will fail to unmarshal the struct. Resolution: Adding the is_abstract member to the Structs InterfaceDescription and FullInterfaceDescription and associated changes to the InterfaceDef interface was an error. The correct way to do this is shown below. A proper resolution to 3015 should recognize that because Abstract Interfaces are a distinct type in IDL, they should be their own type in the IFR as well. This distinction has already been addressed in TypeCodes with create_abstract_interface_tc and tk_abstract_interface. Because the behaviors of interfaces and abstract interfaces are very different, this should also be stressed in the IFR. Consequently, in keeping with the general pattern established with the way abstract interfaces are handled in TypeCodes, it is porposed that AbstractInterfaceDef be defined as an IFR object that represents Abstract Interfaces, and that otherwise has all the attribtues, operations and properties similar to InterfaceDef. This is represented by having AbstractInterfaceDef derive from InterfaceDef, sort of recognizing that an AbstractInterfaceDef IR Object is an InterfaceDef of a special restricted kind. It is necessary to ensure, however, that the base_interfaces of AbstractInterfaceDefs only contain AbstractInterfaceDefs. Also, It is necessary to remove version pragmas atleast from InterfaceDef in order to make sure that a 2.2 InterfaceDef is not rejected as not equivalent to a 2.3 InterfaceDef. Admittedly this is a bit hokey since a 2.3 InterfaceDef derives from a 2.3 Container and hence has additional operations through derivation when compared to 2.2 InterfaceDef, but from an interoperability and backward compatibility perspective this is relatively benign since a 2.3 client attmepting to invoke a 2.3 operation on a 2.2 IFR will merely get a BAD_OPERATION. A 2.2 client will never be able to invoke a 2.3 operation anyway. Since it would then be absurd for a 2.2 (aka 1.0) InterfaceDef to be deriving from a 2.3 Container, it is necessary to remove version pragmas from the transitive closure of the dependency graph for InterfaceDef. It is much easier to remove all version pragmas from IFR interfaces and other IDL entities. It is acknowledged that this is not a complete and clean resolution, but it is also acknowledged that it is impossible to fix all version problems that have accumulated in the IFR due to past carelessness. With these changes, it is believed that pre-2.3 and 2.3 IFR are able to interoperate compatibly with pre 2.3 or 2.3 clients. Future enhancements to IFR should be carried out with greater care and with more attention towards compatibility and cleanliness of versioning. In general, adding new enumerators to enums should not be considered a reason to change the version of the Interface that uses these enums. Other than that, as long as modifications to interfaces are carried out strictly via derivation and other existing IDL entities like structs, unions etc. are considered to be immutable, i.e. the only way to change them is to create a new one with new operations dealing with the new ones, there should be no need to ever use the version pragma. Revised Text: 0. Add a new minor code to the BAD_PARAM exception in Section 3.17.2, that says "Attempt to derive abstract interface from non-abstract base interface in the Interface Repository". [Note: This is necessary to cover for the fact that someone could try to AbstractInterfaceDef::_set_base_interfaces with an InterfaceDefSeq that contains an InterfaceDef that is not an AbstractInterfaceDef.] 1. Add a new enum value dk_AbstractInterface to CORBA::DefinitionKind. This is used as the kind member of the Description struct returned by the inherited describe operation. 2. add create_abstract_interface to CORBA::Container AbstractInterfaceDef create_abstract_interface( in RepositoryId id, in Identifier name, in VersionSpec version in AbstractInterfaceDefSeq base_interfaces ); and add the following text description: The create_abstract_interface operation returns a new empty AbstractInterfaceDef with the specified base_interfaces. Other types can be added in the same way as InterfaceDef allows types to be added. 3. Add a new section 10.5.xx as follows 10.5.xx AbstractInterfaceDef An AbstractInterfaceDef object represents a CORBA 2.3 abstract interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. *Its base interfaces can only contain AbstractInterfaceDefs.* module CORBA { interface AbstractInterfaceDef; typedef sequence AbstractInterfaceDefSeq; interface AbstractInterfaceDef : InterfaceDef { }; 10.5.xx.1 Read Interface [Note: I have filled in the actual text describing the operations from the corresponding text in InterfaceDef, so that minor changes can be made to the text to account for minor differences.] The inherited base_interfaces attribute returns a list of abstract interfaces from which this abstract interface inherits. Note: base_interfaces is of type InterfaceDefSeq, but since AbstractInterfaceDef is derived from InterfaceDef, a list of AbstractInterfaceDefs can legitimately be returned in an InterfaceDefSeq. The inherited is_a operation returns TRUE if the interface on which it is invoked either is identical to or inherits, directly or indirectly, from the abstract interface identified by its interface_id parameter, or if the value of interface_id is IDL:omg.org/CORBA/AbstractBase:1.0 . Otherwise it returns FALSE. The inherited describe_interface operation returns a FullInterfaceDescription describing the abstract interface, including its operations and attributes. The inherited describe operation for an AbstractInterfaceDef returns an InterfaceDescription. The inherited contents operation returns the list of constants, typedefs, and exceptions defined in this AbstractInterfaceDef and the list of attributes and operations either defined or inherited in this AbstractInterfaceDef. If the exclude_inherited parameter is set to TRUE, only attributes and operations defined within this interface are returned. If the exclude_inherited parameter is set to FALSE, all attributes and operations are returned. 10.5.xx.2 Write Interface Setting the inherited base_interfaces attribute causes a BAD_PARAM exception with standard minor code 5 to be raised if the name attribute of any object contained by this AbstractInterfaceDef conflicts with the name attribute of any object contained by any of the specified base AbstractInterfaceDefs. *If any of the InterfaceDefs in base_interface are not AbstractInterfaceDefs then a BAD_PARAM exception with standard minor code is raised.* The inherited create_attribute operation returns a new AttributeDef contained in the AbstractInterfaceDef on which it is invoked. The id, name, version, type_def, and mode attributes are set as specified. The type attribute is also set. The defined_in attribute is initialized to identify the containing AbstractInterfaceDef. An error is returned if an object with the specified id already exists within thiwith the specified name already exists within this AbstractInterfaceDef. The inherited create_operation operation returns a new OperationDef contained in the AbstractInterfaceDef on which it is invoked. The id, name, version, result_def, mode, params, exceptions, and contexts attributes are set as specified. The result attribute is also set. The defined_in attribute is initialized to identify the containing AbstractInterfaceDef. An error is returned if an object with the specified id already exists within thiwithin this AbstractInterfaceDef. 4. Make the following changes to section 10.5.23: First paragraph: An InterfaceDef object represents an interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. IDL: restore this part to as it appeared in CORBA 2.2. module CORBA { interface InterfaceDef; typedef sequence InterfaceDefSeq; typedef sequence RepositoryIdSeq; typedef sequence OpDescriptionSeq; typedef sequence AttrDescriptionSeq; interface InterfaceDef : Container, Contained, IDLType { // read/write interface attribute InterfaceDefSeq base_interfaces; // read interface boolean is_a (in RepositoryId interface_id); struct FullInterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; OpDescriptionSeq operations; AttrDescriptionSeq attributes; RepositoryIdSeq base_interfaces; TypeCode type; }; FullInterfaceDescription describe_interface(); // write interface AttributeDef create_attribute ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType type, in AttributeMode mode ); OperationDef create_operation ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType result, in OperationMode mode, in ParDescriptionSeq params, in ExceptionDefSeq exceptions, in ContextIdSeq contexts ); }; struct InterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; RepositoryIdSeq base_interfaces; }; }; Read interface: Remove the description of the is_abstract attribute. 7. Remove all version pragmas from all IFR related IDL. [Note: This is necessary in order to make sure that a 2.2 InterfaceDef is not rejected as not equivalent to t 2.3 InterfaceDef. Admittedly this is a bit hokey since a 2.3 InterfaceDef derives from a 2.3 Container and hence has additional operations through derivation when compared to 2.2 InterfaceDef, but from an interoperability and backward compatibility perspective this is relatively benign since a 2.3 client attmepting to invoke a 2.3 operation on a 2.2 IFR will merely get a BAD_OPERATION. A 2.2 client will never be able to invoke a 2.3 operation anyway.] s objects object Sender: jbiggar@corvette.floorboard.com Message-ID: <388F5DEE.5CBA2677@floorboard.com> Date: Wed, 26 Jan 2000 12:49:50 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: orb_revision@omg.org, Steve Vinoski , Andrew Watson Subject: Re: Issue 3015 classified as Urgent References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> <388CD407.A921628D@fpk.hp.com> <388CE797.2C05E46E@floorboard.com> <388F47C9.CF3376F6@fpk.hp.com> <388F56AC.5D604072@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Y+U!!e?$!!4>@!!R$hd9 Jishnu Mukerji wrote: > 1. Add a new enum value dk_AbstractInterface to > CORBA::DefinitionKind. > > This is used as the kind member of the Description struct returned > by the > inherited describe operation. Ok, here is a potential failure scenario we need to consider: a CORBA 2.2 IFR client queries the IFR and gets back a Description containing a DefinitionKind of dk_AbstractInterface. The client goes boom because it doesn't understand this enumerator. You may think that this can't happen, since an interface that inherits from an abstract interface can only be provided in post 2.2 IDL, but that is not so. Consider: // IDL #include "CosNaming.idl" abstract interface MyAI { }; interface MyNamingContext : CosNaming::NamingContext, MyAI { }; The client calls Object::get_interface on a Cos::NamingContext reference and gets back an InterfaceDef for MyNamingContext. It then calls describe, and boom! We need to be absolutely clear that we can live with this. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 26 Jan 2000 16:34:49 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar Cc: orb_revision@omg.org, Steve Vinoski , Andrew Watson Subject: Re: Issue 3015 classified as Urgent References: <4.1.20000124152229.018896d0@mail.boston.amer.iona.com> <388CD407.A921628D@fpk.hp.com> <388CE797.2C05E46E@floorboard.com> <388F47C9.CF3376F6@fpk.hp.com> <388F56AC.5D604072@fpk.hp.com> <388F5DEE.5CBA2677@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &#O!!N>ed9-:I!!`?gd9 Jonathan Biggar wrote: > Jishnu Mukerji wrote: > > 1. Add a new enum value dk_AbstractInterface to > CORBA::DefinitionKind. > > > > This is used as the kind member of the Description struct returned > by the > > inherited describe operation. Actually, strictly speaking this is not true. The inherited describe operation returns an InterfaceDescription, just like it does for InterfaceDef. dk_AbstractInterface is indeed returned by the inherited def_kind attribute. BTW, this problem is inherent in any solution that adds a new IRObject and hence a new dk_Something. To avoid this interfaces that use modified enums needs to be versioned, but then that kills their usability for all those cases where it is not a problem. So in balance I think we should allow clients that do not do bounds check to suffer a little. Of course things would have been less confusing if the useless enum thing was not in IDL to start with. > Ok, here is a potential failure scenario we need to consider: a CORBA > 2.2 IFR client queries the IFR and gets back a Description containing a > DefinitionKind of dk_AbstractInterface. The client goes boom because it > doesn't understand this enumerator. > > You may think that this can't happen, since an interface that inherits > from an abstract interface can only be provided in post 2.2 IDL, but > that is not so. Consider: > > // IDL > > #include "CosNaming.idl" > > abstract interface MyAI { }; > > interface MyNamingContext : CosNaming::NamingContext, MyAI { }; > > The client calls Object::get_interface on a Cos::NamingContext reference > and gets back an InterfaceDef for MyNamingContext. It then calls > describe, and boom! > > We need to be absolutely clear that we can live with this. It may go apoplectic when it sees a definition kind that it never heard of through the _get_def_kind operation. We would chalk one up for pitfalls of non-defensive programming.:-) Perhaps what we need to do is add a warning that any client should be ready to deal with IRObjects that it has never heard of before. Unless we do this, there would be no way to add stuff to the IFR in a reasonable way. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: Paul Kyzivat To: orb_revision@omg.org, Andrew Watson Subject: RE: Issue 3015 classified as Urgent Date: Wed, 26 Jan 2000 18:14:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: XgNe9?_Ie9SND!!boJe9 I share Jon's concern. In fact I was about to post on it when Jon beat me to it. It may be something we must live with in this case. But, I don't think we can/should adopt a *general* position that adding new values to an enum is acceptable without a version change. I don't know about other orbs, but we check enun values when unmarshalling. As a result, receiving a reply to a request that contains an enum value inconsistent with the type as we know it will (as it should) result in a MARSHAL exception. Paul > -----Original Message----- > From: Jonathan Biggar [mailto:jon@floorboard.com] > Sent: Wednesday, January 26, 2000 3:50 PM > To: jis@fpk.hp.com > Cc: orb_revision@omg.org; Steve Vinoski; Andrew Watson > Subject: Re: Issue 3015 classified as Urgent > > > Jishnu Mukerji wrote: > > 1. Add a new enum value dk_AbstractInterface to > CORBA::DefinitionKind. > > > > This is used as the kind member of the Description struct > returned by the > > inherited describe operation. > > Ok, here is a potential failure scenario we need to consider: a > CORBA > 2.2 IFR client queries the IFR and gets back a Description > containing a > DefinitionKind of dk_AbstractInterface. The client goes boom > because it > doesn't understand this enumerator. > > You may think that this can't happen, since an interface that > inherits > from an abstract interface can only be provided in post 2.2 IDL, but > that is not so. Consider: > > // IDL > > #include "CosNaming.idl" > > abstract interface MyAI { }; > > interface MyNamingContext : CosNaming::NamingContext, MyAI { }; > > The client calls Object::get_interface on a > Cos::NamingContext reference > and gets back an InterfaceDef for MyNamingContext. It then calls > describe, and boom! > > We need to be absolutely clear that we can live with this. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > Date: Thu, 27 Jan 2000 10:53:23 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: jis@fpk.hp.com, orb_revision@omg.org, Steve Vinoski > , Andrew Watson Subject: Re: Issue 3015 classified as Urgent In-Reply-To: <388F5DEE.5CBA2677@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 5FQ!!jZVd9LNI!!SR"e9 On Wed, 26 Jan 2000, Jonathan Biggar wrote: > // IDL > > #include "CosNaming.idl" > > abstract interface MyAI { }; > > interface MyNamingContext : CosNaming::NamingContext, MyAI { }; > > The client calls Object::get_interface on a Cos::NamingContext > reference > and gets back an InterfaceDef for MyNamingContext. It then calls > describe, and boom! Good catch! > We need to be absolutely clear that we can live with this. Well, I think we can live with this. Not nice (but the alternatives are worse). It's not likely that all the circumstances will come together at once: multiple inheritance using an abstract interface as a mix-in, a DII client using such an interface, and the client crossing a 2.2/2.3 boundary when interrogating the interface repository. I'd expect this to be extremely rare. If it does happen, I guess the price the customer would have to pay is a client-side upgrade of the ORB. But that's a lot better than to shaft *all* DII clients that cross a 2.2/2.3 boundary. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "'jis@fpk.hp.com'" , Jonathan Biggar Cc: orb_revision@omg.org, Steve Vinoski , Andrew Watson Subject: RE: Issue 3015 classified as Urgent Date: Thu, 27 Jan 2000 08:35:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ;jAe94XEe93!X!!!@Ud9 Jishnu, I agree with the warnings to clients about un-heard-of stuff. That would work ok if the enums were instead numeric types with constant values, as has been recent practice for other things. But as I mentioned in my last message, as an enum, we must in general assume that a new value will cause a marshal error in an old recipient. Or are we saying that an orb should permit undefined enum values to be marshalled? Paul > -----Original Message----- > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > Sent: Wednesday, January 26, 2000 4:35 PM > To: Jonathan Biggar > Cc: orb_revision@omg.org; Steve Vinoski; Andrew Watson > Subject: Re: Issue 3015 classified as Urgent > > > Jonathan Biggar wrote: > > > Jishnu Mukerji wrote: > > > 1. Add a new enum value dk_AbstractInterface to > CORBA::DefinitionKind. > > > > > > This is used as the kind member of the Description struct > returned by the > > > inherited describe operation. > > Actually, strictly speaking this is not true. The inherited > describe operation > returns an InterfaceDescription, just like it does for InterfaceDef. > dk_AbstractInterface is indeed returned by the inherited > def_kind attribute. > > BTW, this problem is inherent in any solution that adds a new > IRObject and hence > a new dk_Something. To avoid this interfaces that use > modified enums needs to be > versioned, but then that kills their usability for all those > cases where it is > not a problem. So in balance I think we should allow clients > that do not do > bounds check to suffer a little. Of course things would have > been less confusing > if the useless enum thing was not in IDL to start with. > > > Ok, here is a potential failure scenario we need to > consider: a CORBA > > 2.2 IFR client queries the IFR and gets back a Description > containing a > > DefinitionKind of dk_AbstractInterface. The client goes > boom because it > > doesn't understand this enumerator. > > > > You may think that this can't happen, since an interface > that inherits > > from an abstract interface can only be provided in post 2.2 IDL, > but > > that is not so. Consider: > > > > // IDL > > > > #include "CosNaming.idl" > > > > abstract interface MyAI { }; > > > > interface MyNamingContext : CosNaming::NamingContext, MyAI { }; > > > > The client calls Object::get_interface on a > Cos::NamingContext reference > > and gets back an InterfaceDef for MyNamingContext. It then calls > > describe, and boom! > > > > We need to be absolutely clear that we can live with this. > > It may go apoplectic when it sees a definition kind that it > never heard of > through the _get_def_kind operation. We would chalk one up > for pitfalls of > non-defensive programming.:-) > > Perhaps what we need to do is add a warning that any client > should be ready to > deal with IRObjects that it has never heard of before. Unless > we do this, there > would be no way to add stuff to the IFR in a reasonable way. > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > > Sender: jis@fpk.hp.com Message-ID: <38906831.6B0C6022@fpk.hp.com> Date: Thu, 27 Jan 2000 10:45:53 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: Paul Kyzivat Cc: orb_revision@omg.org Subject: Re: Issue 3015 classified as Urgent References: <9B164B713EE9D211B6DC0090273CEEA914031B@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +=9e9('ld9POl!!]l4!! Paul Kyzivat wrote: > > Jishnu, > > I agree with the warnings to clients about un-heard-of stuff. > That would work ok if the enums were instead numeric types with > constant > values, as has been recent practice for other things. > But as I mentioned in my last message, as an enum, we must in > general assume > that a new value will cause a marshal error in an old recipient. > > Or are we saying that an orb should permit undefined enum values to > be > marshalled? Paul, I don't think that the urgent resolution to 3015 should take a general position on this matter, and to that end I will remove some verbiage that I placed in the resolution discussion before placing it on vote. However, this issue needs to be discussed in the broader context of versioning in CORBA. The other broader issue to be discussed in the context of IFR is how do you in general do backward compatible enhancements to IFR if you are not allowed to add new enumerators to the various ill-conceived enums in the IFR? In addition, how can we get ourselves out of this bind in a backward compatible way, would be a good one to address too. IFR was put together without much thought to future enhancements. There are many things that should have been done differently, and were not. The matter was made worse by careless additions to it over the years. So let us deal with those broader issues separately from this urgent issue. Is that OK? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: Paul Kyzivat To: orb_revision@omg.org Subject: RE: Issue 3015 classified as Urgent Date: Thu, 27 Jan 2000 11:52:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: #f!e9=mE!!`4Q!!D$6e9 Jishnu, I agree that dealing with this urgent issue and the general issue of evolving the spec should be treated separately. w/r/t this urgent issue: in its current form, the current proposal (Steve's with your editorial changes) would cause a MARSHAL error in our ORB in the client when Jon's test case is attempted. I can live with this if others can, since the other simple patches seem to be worse. But I want to make sure that others agree about this. And if this change carries the implication that marshalling of undefined enum values should not produce an error then I think I will be opposed to this change. Paul > -----Original Message----- > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > Sent: Thursday, January 27, 2000 10:46 AM > To: Paul Kyzivat > Cc: orb_revision@omg.org > Subject: Re: Issue 3015 classified as Urgent > > > Paul Kyzivat wrote: > > > > Jishnu, > > > > I agree with the warnings to clients about un-heard-of stuff. > > That would work ok if the enums were instead numeric types > with constant > > values, as has been recent practice for other things. > > But as I mentioned in my last message, as an enum, we must > in general assume > > that a new value will cause a marshal error in an old recipient. > > > > Or are we saying that an orb should permit undefined enum > values to be > > marshalled? > > Paul, > > I don't think that the urgent resolution to 3015 should take > a general position on this matter, and > to that end I will remove some verbiage that I placed in the > resolution discussion before placing it > on vote. However, this issue needs to be discussed in the > broader context of versioning in CORBA. > > The other broader issue to be discussed in the context of IFR > is how do you in general do backward > compatible enhancements to IFR if you are not allowed to add > new enumerators to the various > ill-conceived enums in the IFR? In addition, how can we get > ourselves out of this bind in a backward > compatible way, would be a good one to address too. > > IFR was put together without much thought to future > enhancements. There are many things that should > have been done differently, and were not. The matter was made > worse by careless additions to it over > the years. So let us deal with those broader issues > separately from this urgent issue. Is that OK? > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > Date: Thu, 27 Jan 2000 14:43:38 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat Cc: orb_revision@omg.org Subject: Re: Issue 3015 classified as Urgent References: <9B164B713EE9D211B6DC0090273CEEA914031D@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /*Ee9mBhd9?)#e9%mI!! Paul Kyzivat wrote: > Jishnu, > > I agree that dealing with this urgent issue and the general issue of > evolving the spec should be treated separately. > > w/r/t this urgent issue: in its current form, the current proposal (Steve's > with your editorial changes) would cause a MARSHAL error in our ORB in the > client when Jon's test case is attempted. I can live with this if others > can, since the other simple patches seem to be worse. But I want to make > sure that others agree about this. And if this change carries the > implication that marshalling of undefined enum values should not produce an > error then I think I will be opposed to this change. Either way, whether we accept the new resolution or we fall back on the default old resolution, you will have that problem. You will hit a MARSHAL error on either dk_Interface_2_3 or dk_AbstractInterface or some such. So the choice really is whether you would like to have (a) a solution that has this problem in addition to not quite fixing the problem that it was trying to fix [the default resolution], or would you rather go for (b) a solution that mostly fixes the problem that it set out to fix, but does have this problem [the Steve Vinoski proposal]. The choice is of course yours. I would tend to choose (b). The fundamental problem in IFR is the use of enums. They should not have been used if anyone had thought about implications of using them in evolution of the IFR. I have no idea how that problem can be fixed at this point. As for carrying implication, I as the Chair of the Core RTF will work diligently to make sure that anything adopted in this resolution is not used mindlessly as a precedent to construct more general principles. I am sure you and others will be happy to cooperate on that. As you might have noticed, I removed the language that created such an implication from the resolution, for this very reason. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Sender: andrew@emerald.omg.org Message-Id: Mime-Version: 1.0 Date: Fri, 4 Feb 2000 17:38:38 -0500 To: vendors@omg.org, orbos@omg.org, psdef@omg.org From: Andrew Watson Subject: Resolution of urgent issue 3015 Cc: Core Revision Task Force Content-Type: text/plain; charset="us-ascii" X-UIDL: Lded9"oRd9SZOd9]=-!! Good Afternoon, The CORBA Core RTF has just completed its consideration of issue 3015, which was flagged as urgent to ensure prompt resolution, and prevent vendors having to choose between making their products CORBA 2.3 compliant or backwards compatible with CORBA 2.2. The resolution is attached. Since this was handled as an urgent issue,this resolution should now be considered to be part of the current "Available" CORBA specification, CORBA 2.3.1. This text will be incorporated into the next published CORBA specification. Thanks, Andrew Issue's archive: http://www.omg.org/issues/issue3015.txt Revised Text: 0. Add a new minor code to the BAD_PARAM exception in Section 3.17.2, that says "Attempt to derive abstract interface from non-abstract base interface in the Interface Repository". [Note: This is necessary to cover for the fact that someone could try to AbstractInterfaceDef::_set_base_interfaces with an InterfaceDefSeq that contains an InterfaceDef that is not an AbstractInterfaceDef.] 1. Add a new enum value dk_AbstractInterface to CORBA::DefinitionKind. This is used as the value returned by the inherited def_kind attribute. 2. add create_abstract_interface to CORBA::Container AbstractInterfaceDef create_abstract_interface( in RepositoryId id, in Identifier name, in VersionSpec version in AbstractInterfaceDefSeq base_interfaces ); and add the following text description: The create_abstract_interface operation returns a new empty AbstractInterfaceDef with the specified base_interfaces. Other types can be added in the same way as InterfaceDef allows types to be added. 3. Add a new section 10.5.xx as follows 10.5.xx AbstractInterfaceDef An AbstractInterfaceDef object represents a CORBA 2.3 abstract interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. *Its base interfaces can only contain AbstractInterfaceDefs.* module CORBA { interface AbstractInterfaceDef; typedef sequence AbstractInterfaceDefSeq; interface AbstractInterfaceDef : InterfaceDef { }; 10.5.xx.1 Read Interface [Note: I have filled in the actual text describing the operations from the corresponding text in InterfaceDef, so that minor changes can be made to the text to account for minor differences.] The inherited base_interfaces attribute returns a list of abstract interfaces from which this abstract interface inherits. Note: base_interfaces is of type InterfaceDefSeq, but since AbstractInterfaceDef is derived from InterfaceDef, a list of AbstractInterfaceDefs can legitimately be returned in an InterfaceDefSeq. The inherited is_a operation returns TRUE if the interface on which it is invoked either is identical to or inherits, directly or indirectly, from the abstract interface identified by its interface_id parameter, or if the value of interface_id is IDL:omg.org/CORBA/AbstractBase:1.0 . Otherwise it returns FALSE. The inherited describe_interface operation returns a FullInterfaceDescription describing the abstract interface, including its operations and attributes. The inherited describe operation for an AbstractInterfaceDef returns an InterfaceDescription. The inherited contents operation returns the list of constants, typedefs, and exceptions defined in this AbstractInterfaceDef and the list of attributes and operations either defined or inherited in this AbstractInterfaceDef. If the exclude_inherited parameter is set to TRUE, only attributes and operations defined within this interface are returned. If the exclude_inherited parameter is set to FALSE, all attributes and operations are returned. 10.5.xx.2 Write Interface Setting the inherited base_interfaces attribute causes a BAD_PARAM exception with standard minor code 5 to be raised if the name attribute of any object contained by this AbstractInterfaceDef conflicts with the name attribute of any object contained by any of the specified base AbstractInterfaceDefs. *If any of the InterfaceDefs in base_interface are not AbstractInterfaceDefs then a BAD_PARAM exception with standard minor code is raised.* The inherited create_attribute operation returns a new AttributeDef contained in the AbstractInterfaceDef on which it is invoked. The id, name, version, type_def, and mode attributes are set as specified. The type attribute is also set. The defined_in attribute is initialized to identify the containing AbstractInterfaceDef. An error is returned if an object with the specified id already exists within this object?s Repository, or if an object with the specified name already exists within this AbstractInterfaceDef. The inherited create_operation operation returns a new OperationDef contained in the AbstractInterfaceDef on which it is invoked. The id, name, version, result_def, mode, params, exceptions, and contexts attributes are set as specified. The result attribute is also set. The defined_in attribute is initialized to identify the containing AbstractInterfaceDef. An error is returned if an object with the specified id already exists within this object?s Repository, or if an object with the specified name already exists within this AbstractInterfaceDef. 4. Make the following changes to section 10.5.23: First paragraph: restore it to as it was before 2.3. An InterfaceDef object represents an interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. IDL: restore this part to as it appeared in CORBA 2.2. module CORBA { interface InterfaceDef; typedef sequence InterfaceDefSeq; typedef sequence RepositoryIdSeq; typedef sequence OpDescriptionSeq; typedef sequence AttrDescriptionSeq; interface InterfaceDef : Container, Contained, IDLType { // read/write interface attribute InterfaceDefSeq base_interfaces; // read interface boolean is_a (in RepositoryId interface_id); struct FullInterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; OpDescriptionSeq operations; AttrDescriptionSeq attributes; RepositoryIdSeq base_interfaces; TypeCode type; }; FullInterfaceDescription describe_interface(); // write interface AttributeDef create_attribute ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType type, in AttributeMode mode ); OperationDef create_operation ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType result, in OperationMode mode, in ParDescriptionSeq params, in ExceptionDefSeq exceptions, in ContextIdSeq contexts ); }; struct InterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; RepositoryIdSeq base_interfaces; }; }; Read interface: Remove the description of the is_abstract attribute. 7. Remove all version pragmas from all IFR related IDL. [Note: This is necessary in order to make sure that a 2.2 InterfaceDef is not rejected as not equivalent to t 2.3 InterfaceDef. Admittedly this is a bit hokey since a 2.3 InterfaceDef derives from a 2.3 Container and hence has additional operations through derivation when compared to 2.2 InterfaceDef, but from an interoperability and backward compatibility perspective this is relatively benign since a 2.3 client attempting to invoke a 2.3 operation on a 2.2 IFR will merely get a BAD_OPERATION. A 2.2 client will never be able to invoke a 2.3 operation anyway. There are cases where a 2.2 client may get back a 2.3 IRObject containing a dk_* value that is unknown to the 2.2 client. In the better written ORBs these will cause MARSHAL exception due to failure to unmarshal the unknown value of an enumerator. In other ORBs the client may have a problem if it is not programmed defensively.] Sender: jon@corvette.floorboard.com Message-ID: <389B9F78.7D2D7F6E@floorboard.com> Date: Fri, 04 Feb 2000 19:56:40 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Watson CC: vendors@omg.org, orbos@omg.org, psdef@omg.org, Core Revision Task Force Subject: Re: Resolution of urgent issue 3015 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~H^d9M1!e9i#(!!BY!!! Andrew Watson wrote: > > Good Afternoon, > > The CORBA Core RTF has just completed its consideration of issue > 3015, > which was flagged as urgent to ensure prompt resolution, and prevent > vendors having to choose between making their products CORBA 2.3 > compliant > or backwards compatible with CORBA 2.2. > > The resolution is attached. Since this was handled as an urgent > issue,this > resolution should now be considered to be part of the current > "Available" > CORBA specification, CORBA 2.3.1. This text will be incorporated > into the > next published CORBA specification. > 0. Add a new minor code to the BAD_PARAM exception in Section 3.17.2, > that says > "Attempt to derive abstract interface from non-abstract base interface in the > Interface Repository". It seems to me that this is not complete until an actual value is assigned to this minor code rather than . -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sat, 05 Feb 2000 10:36:13 -0500 From: Jishnu Mukerji X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar Cc: Andrew Watson , vendors@omg.org, orbos@omg.org, psdef@omg.org, Core Revision Task Force Subject: Re: Resolution of urgent issue 3015 References: <389B9F78.7D2D7F6E@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 80hd9#N0!!:%He9G@"e9 It actually has been. The value is 11. It is a typo in the resolution that I sent Andrew. Andrew could you please substitute 11 in place of ? I will double check and verify the value on Monday and let you know if 11 is wrong. Thanks, Jishnu. Jonathan Biggar wrote: > Andrew Watson wrote: > > > > Good Afternoon, > > > > The CORBA Core RTF has just completed its consideration of issue > 3015, > > which was flagged as urgent to ensure prompt resolution, and > prevent > > vendors having to choose between making their products CORBA 2.3 > compliant > > or backwards compatible with CORBA 2.2. > > > > The resolution is attached. Since this was handled as an urgent > issue,this > > resolution should now be considered to be part of the current > "Available" > > CORBA specification, CORBA 2.3.1. This text will be incorporated > into the > > next published CORBA specification. > > > 0. Add a new minor code to the BAD_PARAM exception in > Section 3.17.2, > > that says > > "Attempt to derive abstract interface from non-abstract base > interface in the > > Interface Repository". > > It seems to me that this is not complete until an actual value is > assigned to this minor code rather than . > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org