Issue 2378: Try to define obligatory and optional parts of the CORBA specification. (orb_revision) Source: (, ) Nature: Revision Severity: Minor Summary: Summary: This comment uses examples from the chapter 3, but its idea concernes style of the all specification, as a general rule. 6) In the version CORBA 2.2, there were introduced new features and new simple data type. I understand, that such types like long long and/or long double may be key parts for some application. On the other hand, majority of applications need not such data types, and I see no reason to introduce them as obligatory to all CORBA implementations. For this reason, try to difference various features as obligatory for any CORBA compliant implementation and other ones as optional. In general, it is good idea to specify advanced features of this system to unify various its implementators, but, on the other hand, why those features are made obligatory? For this reason, try to define obligatory and optional parts of the CORBA specification. Resolution: Close in 2.4 with no change. Revised Text: Creating multiple conformance points will make the management of conformance problem very difficult and will make interoperability considerably more difficult thus defeating the very purpose and one of the cornerstones of the success of CORBA. The implementation of a particular application may use whatever subset it chooses but the at the interface the entire set of types must be supported. Actions taken: February 2, 1999: received issue September 16, 1999: closed issue Discussion: End of Annotations:===== Date: Tue, 2 Feb 1999 06:21:06 -0500 (EST) From: jsoler@csc.com To: juergen@omg.org, web-incoming@omg.org Subject: Issue Report Name: Jiri Soler Company: CSC Computer Sciences mailFrom: jsoler@csc.com Notification: Yes Specification: Common Object Request Broker: Architecture and Specification, revision 2.2 Section: 3.8 Formal #: 98-07-01 Version: Revision_Date: 02/1988 Page: 3-22 Nature: Revision Severity: Minor full_desc: This comment uses examples from the chapter 3, but its idea concernes style of the all specification, as a general rule. 6) In the version CORBA 2.2, there were introduced new features and new simple data type. I understand, that such types like long long and/or long double may be key parts for some application. On the other hand, majority of applications need not such data types, and I see no reason to introduce them as obligatory to all CORBA implementations. For this reason, try to difference various features as obligatory for any CORBA compliant implementation and other ones as optional. In general, it is good idea to specify advanced features of this system to unify various its implementators, but, on the other hand, why those features are made obligatory? For this reason, try to define obligatory and optional parts of the CORBA specification. submit: Submit Issue Report Date: Tue, 02 Feb 1999 22:20:08 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard New Jersey Laboratories To: Juergen Boldt CC: issues@emerald.omg.org, orb_revision@emerald.omg.org Subject: Re: issues 2372-2373, issues 2375-2378 --Core Issues (?) References: <3.0.32.19990202112046.007624e8@emerald.omg.org> 2373, 2375 and 2376 are C++ issues, and mostly obsolete issues too probably. 2372 is a Core issue, but according to the author it is really not an important issue, as s/he says "In fact, the problem is not so hot, as it may seem on the first view. I know at present no classical compiler allowing use of the national character set e.g. for the language identifiers, and the limitation of the character sets to pure Latin characters is considered by Czech (and other nation's) programmers as no significant limitation, with exception of the comments. The same concerns CORBA identifiers used in the OMG IDL language." so based on that advise I will be happy to write up a resolution for the next round of votes in the Core RTF to close it no change;-) Issue 2377 could be sent to IONA:-) Issue 2378 wants us to define different compliance points in Chapter 3. I think several other more spectacular events, like hell freezing over comes to mind, would probably take place before things like long long will become an optional conformance point in Chapter 3 (just my humble opinion of course:-)). My inclination would be to propose closing this issue with no change and an explanation that all of Chapter 3 is mandatory, in the next vote in the Core RTF. Cheers, Jishnu Mukerji jis@fpk.hp.com Date: Wed, 3 Feb 1999 14:01:45 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: orb_revision@emerald.omg.org, cxx_revision@omg.org Subject: Re: issues 2372-2373, issues 2375-2378 --Core Issues (?) Organization: Triodia Technologies On Tue, 2 Feb 1999, Jishnu Mukerji wrote: > 2373, Fixed in the 1.4 mapping (Issue 189). Close no change. > 2375 The code in the 1.4 mapping compiles fine as it stands. I suspect that the author of the issue made a mistake when adding the dummy declaration. Close no change. > 2376 I think the author has a point there, at least with the POA. Previously, the _out classes were essential in the collocated case for ORBs that implement reference for collocated servants a direct pointer to the servant. In that case, there is no way to intercept the call chain to deallocate the previous value of an out parameter, so the _out type is crucial. However, with the POA mapping, I think we could do away with the _out classes. That's because the POA requires an intervening class instance even in the collocated case. I think we could deallocate the memory for out parameters from the proxy instead. However, I believe that the _out classes are nowhere near as serious an impediment as the author would have me believe -- they are transparent to the client code. > are C++ issues, and mostly obsolete issues too > probably. Yes, except for 2376, which we can discuss in cxx_revision. > 2372 is a Core issue, but according to the author it is really not an > important issue, as s/he says "In fact, the problem is not so hot, as it > may seem on the first view. I > know at present no classical compiler allowing use of the national > character set e.g. for the language identifiers, and the limitation of > the > character sets to pure Latin characters is considered by Czech (and > other > nation's) programmers as no significant limitation, with exception of > the > comments. The same concerns CORBA identifiers used in the OMG IDL > language." > > so based on that advise I will be happy to write up a resolution for the > next round of votes in the Core RTF to close it no change;-) I thought we discussed this ad nauseam in the past? IDL no longer permits non-ASCII letter and digits for identifiers. For I18N support, wchar and wstring are available. > Issue 2377 could be sent to IONA:-) Close no change. I think this is adequately dealt with by the POA spec. > Issue 2378 wants us to define different compliance points in Chapter 3. > I think several other more spectacular events, like hell freezing over > comes to mind, would probably take place before things like long long > will become an optional conformance point in Chapter 3 (just my humble > opinion of course:-)). My inclination would be to propose closing this > issue with no change and an explanation that all of Chapter 3 is > mandatory, in the next vote in the Core RTF. Well, that one is quite serious in my opinion. I have asked a similar question several times in the past (with CC to the architecture board) but never received an answer. The reality is that to support the extended IDL types, especially long double and long long, without native support is very difficult, to say the least. Moreover, we do not have mappings for these types where they are not directly supported by a language-specific type. For example, to support long double or long long on 32-bit platforms, ORB vendors would have to pretty much bundle a full floating-point emulation library. In addition, MinimumCORBA requires full support for IDL types. It would be interesting to see how vendors manage to squeeze support for these types into 16-bit or 32-bit embedded systems... In my opinion, the rushed addition of these extended IDL types was a big mistake because no-one really bothered to think about the consequences. In particular, interoperability goes *completely* out the window. For example, a CORBA 2.0 event channel cannot move events that originate from a 2.2 server if the event contains, say, a long double or a fixed-point value. That's because a 2.0 ORB has no idea how to unmarshal that stuff (but, to retransmit the event, the any has to be unmarshaled). There are quite a few similar scenarios where interoperability is broken. (Any time a 2.0 ORB gets a TypeCode for one of the extended types from somewhere else, it can do nothing but throw up its hands in despair.) I still would like to see an official statement as to the optionality or otherwise of the new IDL types added with CORBA 2.1. Without such a statement, any notion of compliance testing becomes a joke (you could not even guarantee on-the-wire interoperability for built-in IDL types). Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Wed, 03 Feb 1999 12:59:25 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard New Jersey Laboratories To: Michi Henning CC: orb_revision@emerald.omg.org Subject: Re: issues 2372-2373, issues 2375-2378 --Core Issues (?) References: Michi Henning wrote: > > Issue 2378 wants us to define different compliance points in Chapter 3. > > I think several other more spectacular events, like hell freezing over > > comes to mind, would probably take place before things like long long > > will become an optional conformance point in Chapter 3 (just my humble > > opinion of course:-)). My inclination would be to propose closing this > > issue with no change and an explanation that all of Chapter 3 is > > mandatory, in the next vote in the Core RTF. > > Well, that one is quite serious in my opinion. I have asked a similar question > several times in the past (with CC to the architecture board) but never > received an answer. > > The reality is that to support the extended IDL types, especially long double > and long long, without native support is very difficult, to say the least. Depends on what you mean by "support". Marshaling them for passing through interfaces can certainly be done, modulo the point you make immediately below, even without native support. > Moreover, we do not have mappings for these types where they are not > directly supported by a language-specific type. That's a good point, and should be raised as a separate issue. However, purely at an interface specification level this is not a hugely difficult thing to do, one jsut needs to state precisely what is tobe done. What the receiving program does with one of these is where the business of libraries comes in. > For example, to support long double or long long on 32-bit platforms, ORB > vendors would have to pretty much bundle a full floating-point emulation > library. Yep, that would be one of the possible ways of providing an implementation of these types, and it doeen's even have to be a good, efficient library. It just has to barely hobble along.:-) > In addition, MinimumCORBA requires full support for IDL types. > It would be interesting to see how vendors manage to squeeze support > for > these types into 16-bit or 32-bit embedded systems... > Heh heh.... again, depends on what you mean by "supports". I don't think that requiring that all ORBs of a particular vintage or later are able to receive and transmit these types through interfaces says much about how their handling within the program doing said receiving and transmitting takes place. That's an implementation issue,:-) and strictly speaking, I don't think one needs to be able to do arithmetic with these types in order to comply with Chapter 3. The platform on which the IDL compiler runs (or at least the IDL compiler itself) does need to be able to do at least the constant arithmetic for cosntant expressions in IDL, but the deployment platform is a separate issue. The intent among the minCORBA submitters I think was to be able to receive and transmit these types for compatibility with full ORBs. > In my opinion, the rushed addition of these extended IDL types was a big > mistake because no-one really bothered to think about the consequences. > In particular, interoperability goes *completely* out the window. For > example, a CORBA 2.0 event channel cannot move events that originate from > a 2.2 server if the event contains, say, a long double or a fixed-point > value. That's because a 2.0 ORB has no idea how to unmarshal that stuff > (but, to retransmit the event, the any has to be unmarshaled). There > are quite a few similar scenarios where interoperability is broken. (Any > time a 2.0 ORB gets a TypeCode for one of the extended types from somewhere > else, it can do nothing but throw up its hands in despair.) Well, for arguments sake let me take the following extreme position: I think it is perfectly all right for a 2.0 ORB to throw up its hands when it receives a typecode that was introduced in a later rev of the spec. They'll also do so when an OBV comes in and bites them in the rear.:-) I don't think people should harbor magical expectations that old versions of software will suddenly become aware of new concepts that were added in later versions of the software. It is the responsibility of the user of the software to ensure that the software adequately support all features needed for the particular project. In short, if someone wants to use events which contain post 2.1 introduced types they will need to upgrade all the ORBs through which such events pass to the appropriate vintage. What is wrong with this? > I still would like to see an official statement as to the optionality or > otherwise of the new IDL types added with CORBA 2.1. Without such a statement, > any notion of compliance testing becomes a joke (you could not even guarantee > on-the-wire interoperability for built-in IDL types). > Sure you can, as long as it is between 2.3 or later ORB and 2.3 or later ORB (modulo that language mapping issue, and the brokenness of the Fixed Point stuff of course:-) - those should naturally be fixed) Cheers, Jishnu. Date: Thu, 4 Feb 1999 10:43:50 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: orb_revision@emerald.omg.org Subject: Re: issues 2372-2373, issues 2375-2378 --Core Issues (?) Organization: Triodia Technologies On Wed, 3 Feb 1999, Jishnu Mukerji wrote: > > For example, to support long double or long long on 32-bit platforms, ORB > > vendors would have to pretty much bundle a full floating-point emulation > > library. > > Yep, that would be one of the possible ways of providing an implementation of > these types, and it doeen's even have to be a good, efficient library. It just has > to barely hobble along.:-) Even one that just barely hobbles along makes for quite a bit of effort. > > In addition, MinimumCORBA requires full support for IDL types. > > It would be interesting to see how vendors manage to squeeze > support for > > these types into 16-bit or 32-bit embedded systems... > > > > Heh heh.... again, depends on what you mean by "supports". I don't > think that > requiring that all ORBs of a particular vintage or later are able to > receive and > transmit these types through interfaces says much about how their > handling within > the program doing said receiving and transmitting takes > place. That's an > implementation issue,:-) and strictly speaking, I don't think one > needs to be able > to do arithmetic with these types in order to comply with Chapter 3. Yes. On the other hand, I can see precious little point in getting a long long or a long double from somewhere if I can't do computation with it. After all, if I can't do that, there seems little point in obtaining the value in the first place. > The platform > on which the IDL compiler runs (or at least the IDL compiler itself) > does need to > be able to do at least the constant arithmetic for cosntant > expressions in IDL, > but the deployment platform is a separate issue. The intent among > the minCORBA > submitters I think was to be able to receive and transmit these > types for > compatibility with full ORBs. Yes. In many ways, requiring full IDL compliance for MinCORBA was a good idea, IMO. It's the need for long double and long long in the first place I am doubtful about. And I am very doubtful about the way in which they were added, completely neglegting the on-the-wire issues. > Well, for arguments sake let me take the following extreme position: I think it is > perfectly all right for a 2.0 ORB to throw up its hands when it receives a > typecode that was introduced in a later rev of the spec. They'll also do so when > an OBV comes in and bites them in the rear.:-) I don't think people should harbor > magical expectations that old versions of software will suddenly become aware of > new concepts that were added in later versions of the software. Completely agree. That's what I call "forward compatibility", which is an oxymoron ;-) > It is the > responsibility of the user of the software to ensure that the > software adequately > support all features needed for the particular project. In short, if > someone wants > to use events which contain post 2.1 introduced types they will need > to upgrade > all the ORBs through which such events pass to the appropriate > vintage. What is > wrong with this? That I have absolutely no way of finding out whether that precondition is actually met, neither at compile time, nor at run time. Of course, that's in the nature of the event service. > > I still would like to see an official statement as to the optionality or > > otherwise of the new IDL types added with CORBA 2.1. Without such a statement, > > any notion of compliance testing becomes a joke (you could not even guarantee > > on-the-wire interoperability for built-in IDL types). > > > > Sure you can, as long as it is between 2.3 or later ORB and 2.3 or later ORB > (modulo that language mapping issue, and the brokenness of the Fixed Point stuff > of course:-) - those should naturally be fixed) But the spec never revved the GIOP version number when the new types were added, depriving the sending ORB from ever detecting that the data it is sending may not be able to be decoded... I guess it's all water under the bridge now... But of course, I'm not going to run out of ammunition because the current interceptor spec will keep me supplied for some time to come :-) Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html