Issue 1707: New IDL types (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: When the new IDL types were added (fixed, long double, etc), no new IIOP or GIOP version was introduced, and no new version of CDR was introduced. Instead, the marshaling rules for the new types were simply added to CDR, and the type code interface was extended to handle these. Unfortunately, this creates some rather serious problems for interoperability. Resolution: Revised Text: Actions taken: July 21, 1998: received issue February 17, 1999: closed issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 21 Jul 1998 17:41:19 +1000 (EST) From: Michi Henning To: issues@omg.org, interop@omg.org, obv-rtf@omg.org Subject: New IDL types Note: I've added the obv-rtf to the CC list because I think this may also affect OBV. When the new IDL types were added (fixed, long double, etc), no new IIOP or GIOP version was introduced, and no new version of CDR was introduced. Instead, the marshaling rules for the new types were simply added to CDR, and the type code interface was extended to handle these. Unfortunately, this creates some rather serious problems for interoperability. For example, consider an event service that was built using CORBA 2.1, before the new types were added. Now I have an ORB that supports long double or long long, and I send a long long value inside an any to that event channel. Of course, the event channel doesn't understand type long long and I will most likely get spurious marshaling errors. Similar things will happen for wide strings, wide characters, and fixed-point values. It's a little late to do something about this. However, I'm not impressed that new types were added without giving even a second thought to what this means for on-the-wire interoperability. Because no new version of GIOP was added, I have lost all means of figuring out whether a particular event channel (or other interface accepting type any) can handle the new IDL types. I can't figure it out at compile time, and I can't figure it out at run time. Not nice... I'm not sure what the implications are for the OBV effort. As far as I can see, the submission mentions a new protocol version, but I can't find statements as to what is compatible with what else off-hand. In particular, how are encapsulations dealt with? Specifically, what if an encapsulation contains an any which in turn contains a value? How do we ensure that this encapsulation isn't mistakenly passed to a down-stream receiver that is still at GIOP 1.1 level and therefore cannot decode the encapsulation? Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: From: Jeffrey Mischkinsky Subject: Re: New IDL types To: michi@dstc.edu.au (Michi Henning) Date: Tue, 21 Jul 1998 15:18:32 -0700 (PDT) Cc: interop@omg.org, obv-rtf@omg.org 'Michi Henning' writes: > > Note: I've added the obv-rtf to the CC list because I think this may > also affect OBV. i don't think so, at least not explicitly. In general i think Michi's observations are correct. The data types that are encoded/supported are part of the definition of a particular version of GIOP. The issue with how the extended types were added is just another aspect of not paying enough attention to the details. We've known that the GIOP version includes the data types, and unfortunately there is probably a bit of confusion as to what GIOP 1.1 includes. The best rule of thumb i can think of is: if it is in CORBA 2.2, then its in GIOP 1.1 if it is in CORBA 2.1 and not CORBA 2.2 then i think we have a problem. And i can't think of a good way to solve it, since the information simply isn't in the protocol. The problem will go away with CORBA 2.3, since it will define GIOP 1.2 and clearly all the of the "new" datatypes fixed, long long, value, etc. are in it. In the future, we have to make sure that any additions to IDL dataatypes must rev the GIOP level. Values have value tags preceding them, which are not valid for GIOP 1.1, and should not be sent to a 1.1 receiver. The sending side knows what kind of reciever it is talking to. So i don't think there will be a problem. jeff > > When the new IDL types were added (fixed, long double, etc), no new > IIOP or GIOP version was introduced, and no new version of CDR was > introduced. > Instead, the marshaling rules for the new types were simply added to > CDR, > and the type code interface was extended to handle these. > > Unfortunately, this creates some rather serious problems for > interoperability. > For example, consider an event service that was built using CORBA > 2.1, > before the new types were added. Now I have an ORB that supports > long double > or long long, and I send a long long value inside an any to that > event channel. > Of course, the event channel doesn't understand type long long and I > will > most likely get spurious marshaling errors. Similar things will > happen > for wide strings, wide characters, and fixed-point values. > > It's a little late to do something about this. However, I'm not > impressed > that new types were added without giving even a second thought to > what > this means for on-the-wire interoperability. Because no new version > of GIOP was added, I have lost all means of figuring out whether a > particular > event channel (or other interface accepting type any) can handle the > new IDL types. I can't figure it out at compile time, and I can't > figure > it out at run time. Not nice... > > I'm not sure what the implications are for the OBV effort. As far as > I > can see, the submission mentions a new protocol version, but I can't > find > statements as to what is compatible with what else off-hand. > > In particular, how are encapsulations dealt with? Specifically, what > if > an encapsulation contains an any which in turn contains a value? How > do we ensure that this encapsulation isn't mistakenly passed to a > down-stream > receiver that is still at GIOP 1.1 level and therefore cannot decode > the > encapsulation? > > Cheers, > > Michi. > -- > Michi Henning +61 7 33654310 > DSTC Pty Ltd +61 7 33654311 (fax) > University of Qld 4072 michi@dstc.edu.au > AUSTRALIA > http://www.dstc.edu.au/BDU/staff/michi-henning.html > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-312-5158 jeffm@visigenic.com +1 650-312-5158 Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 22 Jul 1998 09:30:31 +1000 (EST) From: Michi Henning To: Jeffrey Mischkinsky cc: interop@omg.org, obv-rtf@omg.org Subject: Re: New IDL types On Tue, 21 Jul 1998, Jeffrey Mischkinsky wrote: > In the future, we have to make sure that any additions to IDL dataatypes must > rev the GIOP level. > > Values have value tags preceding them, which are not valid for GIOP 1.1, > and should not be sent to a 1.1 receiver. The sending side knows what kind > of reciever it is talking to. So i don't think there will be a problem. The recent discussions about the type code caching ideas have shown that adding new marshaling rules and data types is a lot more subtle than first meets the eye. In particular, encapsulations are dangerous, because if an encapsulation contains a new type, it cannot be forwarded to a receiver that doesn't know about the new types. Because values can be inside anys, there no guarantee in general that the sender can determine whether it is safe to send a particular any value to the receiver. The only way I can see to make this work is to have a new protocol version, and some very strict rules about what kind of encoding can be sent where and under what circumstances. There is also the issue of encapsulations inside IORs. At any rate, I suspect the OBV submission will have to say quite a bit more than it does currently to make this work. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Tue, 21 Jul 1998 16:51:55 -0700 From: Jonathan Biggar To: Jeffrey Mischkinsky CC: Michi Henning , interop@omg.org, obv-rtf@omg.org Subject: Re: New IDL types References: <199807212218.PAA17804@wheel.dcn.davis.ca.us> Jeffrey Mischkinsky wrote: > The best rule of thumb i can think of is: > if it is in CORBA 2.2, then its in GIOP 1.1 > if it is in CORBA 2.1 and not CORBA 2.2 then i think we have a > problem. > And i can't think of a good way to solve it, since the information > simply > isn't in the protocol. > > The problem will go away with CORBA 2.3, since it will define GIOP > 1.2 > and clearly all the of the "new" datatypes fixed, long long, > value, etc. > are in it. > > In the future, we have to make sure that any additions to IDL > dataatypes must > rev the GIOP level. > > Values have value tags preceding them, which are not valid for GIOP > 1.1, > and should not be sent to a 1.1 receiver. The sending side knows > what kind > of reciever it is talking to. So i don't think there will be a > problem. I suppose this is a problem with any introspection facility whenever you revise the meta-types (meta-introspection anyone?) However this does raise the question of whether the sender must explicitly determine that it is only sending information that the receiver understands. If we are making a new requirement that the sender vet everything it sends against the receivers GIOP version then we need to make that quite explicit. It seems to me that this places a large burden on Event or Notification servers, since these new data types can be buried quite deep in an any that the server otherwise would have no reason to look at. I would prefer that the responsibility be left to the receiver that needs to interpret the data. Another thing to consider is what exception is appropriate to raise when attempting to send unsupported data types. MARSHAL is an obvious candidate, but it doesn't really have the right connotation, since this is not strickly a marshaling error, instead it is a version error. We are probably stuck with MARSHAL, however, because that is what a receiver will raise when it receives an unknown TCKind. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: Jeffrey Mischkinsky Subject: Re: New IDL types To: jon@floorboard.com (Jonathan Biggar) Date: Tue, 21 Jul 1998 19:04:07 -0700 (PDT) Cc: michi@dstc.edu.au, interop@omg.org, obv-rtf@omg.org 'Jonathan Biggar' writes: > > Jeffrey Mischkinsky wrote: > > The best rule of thumb i can think of is: > > if it is in CORBA 2.2, then its in GIOP 1.1 > > if it is in CORBA 2.1 and not CORBA 2.2 then i think we have a > problem. > > And i can't think of a good way to solve it, since the > information simply > > isn't in the protocol. > > > > The problem will go away with CORBA 2.3, since it will define > GIOP 1.2 > > and clearly all the of the "new" datatypes fixed, long long, > value, etc. > > are in it. > > > > In the future, we have to make sure that any additions to IDL > dataatypes must > > rev the GIOP level. > > > > Values have value tags preceding them, which are not valid for > GIOP 1.1, > > and should not be sent to a 1.1 receiver. The sending side knows > what kind > > of reciever it is talking to. So i don't think there will be a > problem. > > However this does raise the question of whether the sender must > explicitly determine that it is only sending information that the > receiver understands. If we are making a new requirement that the > sender vet everything it sends against the receivers GIOP version > then > we need to make that quite explicit. It seems to me that this > places a > large burden on Event or Notification servers, since these new data > types can be buried quite deep in an any that the server otherwise > would > have no reason to look at. I would prefer that the responsibility > be > left to the receiver that needs to interpret the data. I believe the situation is as follows. An IOR specifies what version the server is prepared to support. According to the spec, a 1.1 server must be able to support 1.0 and 1.1, AND respond using the same version as the request it receives uses. I guess implicit in this is that when using an IOR which only supports 1.0, a client is not allowed to send 1.1 message and can expect to receive an exception back if the request heeder identifies the message as a 1.1 message. So i'm not sure where the problem lies--except as was pointed out with encapsulations are certain circumstances. The supported datatypes are part of the definition of the GIOP version. Even if we've been a little sloppy in documenting that explicitly. jeff > > Another thing to consider is what exception is appropriate to raise > when > attempting to send unsupported data types. MARSHAL is an obvious > candidate, but it doesn't really have the right connotation, since > this > is not strickly a marshaling error, instead it is a version error. > We > are probably stuck with MARSHAL, however, because that is what a > receiver will raise when it receives an unknown TCKind. -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-312-5158 jeffm@visigenic.com +1 650-312-5158 Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 22 Jul 1998 12:47:10 +1000 (EST) From: Michi Henning To: Jeffrey Mischkinsky cc: Jonathan Biggar , interop@omg.org, obv-rtf@omg.org Subject: Re: New IDL types On Tue, 21 Jul 1998, Jeffrey Mischkinsky wrote: > I believe the situation is as follows. An IOR specifies what version > the server is prepared to support. > According to the spec, a 1.1 server must be able to support 1.0 and > 1.1, AND > respond using the same version as the request it receives uses. > I guess implicit in this is that when using an IOR which only > supports 1.0, > a client is not allowed to send 1.1 message and can expect to > receive an > exception back if the request heeder identifies the message as a 1.1 > message. > > So i'm not sure where the problem lies--except as was pointed out > with > encapsulations are certain circumstances. Well, I cannot ever send an Any value from a 1.2 sender to a 1.1 receiver unless I have first made sure that none of the encapsulations that possibly may be inside the any contain values that only exist in 1.2. This not only requires me to break open the encapsulation and to decode it to look for 1.2 values, it also means I must be able to do this for both byte orders, because an encapsulated value may have different byte ordering. At least this much must be explicitly stated. Further, IORs must be restrictied to only contain encapsulations for 1.1 because otherwise an IOR passed to 1.1 receiver may end up containing 1.2 encoded data. In addition, GIOP 1.2 must be specified to support both old and new CDR formats. We also need state that 1.0 and 1.1 cannot be used with the new CDR formats. And we need to state that a 1.2 type code cannot be sent to a 1.1 or 1.0 receiver. I think that captures the majority of cases, but there may be others I didn't think of. There is also the issue of how to recognize encapsulations - I think a CDR version identifier along the lines of what we discussed for the cached type code proposal will be necessary. Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Tue, 21 Jul 1998 23:40:38 -0400 From: Bob Kukura Organization: IONA Technologies To: Michi Henning CC: Jeffrey Mischkinsky , Jonathan Biggar , interop@omg.org, obv-rtf@omg.org Subject: Re: New IDL types References: Michi Henning wrote: > > On Tue, 21 Jul 1998, Jeffrey Mischkinsky wrote: > > > I believe the situation is as follows. An IOR specifies what > version > > the server is prepared to support. > > According to the spec, a 1.1 server must be able to support 1.0 > and 1.1, AND > > respond using the same version as the request it receives uses. > > I guess implicit in this is that when using an IOR which only > supports 1.0, > > a client is not allowed to send 1.1 message and can expect to > receive an > > exception back if the request heeder identifies the message as a > 1.1 message. > > > > So i'm not sure where the problem lies--except as was pointed out > with > > encapsulations are certain circumstances. > > Well, I cannot ever send an Any value from a 1.2 sender to a 1.1 > receiver > unless I have first made sure that none of the encapsulations that > possibly > may be inside the any contain values that only exist in 1.2. This > not > only requires me to break open the encapsulation and to decode it to > look > for 1.2 values, it also means I must be able to do this for both > byte orders, because an encapsulated value may have different byte > ordering. > > At least this much must be explicitly stated. I think this supports my position against using encapsulations for Any values, or for TypeCodes, for that matter. If an ORB keeps an encapsulation around without interpreting it, it cannot forward it to a lower versioned ORB than that from which it was recieved without ensuring it is legal for the lower version. This is just as serious a problem for TypeCodes, when new TCKinds are introduced, as it is for the value portion of Anys. > > Further, IORs must be restrictied to only contain encapsulations for > 1.1 > because otherwise an IOR passed to 1.1 receiver may end up > containing > 1.2 encoded data. I think each profile, component, and service tag definition that uses encapsulations should state which CDR version is used. If the tag isn't recognized, it doesn't matter if the encapsulation is an unknown version. New profiles, components, and service contexts can be defined to use the CDR version corresponding to the GIOP version in which they are introduced. If GIOP 1.2 supports value types, tags defined for 1.2, and not for earlier GIOP version, can use value types. I don't think we are in trouble yet, since, as far as I know, none of the standard profile, component, or service bodies contain Anys, TypeCodes, extended data types, or Value types, so they are all effectively CDR 1.0. > > In addition, GIOP 1.2 must be specified to support both old and new > CDR formats. We also need state that 1.0 and 1.1 cannot be used with > the > new CDR formats. And we need to state that a 1.2 type code cannot be > sent > to a 1.1 or 1.0 receiver. The negotiated GIOP version needs to imply the specific CDR version for the GIOP message streams, including the allowed IDL types. GIOP's minor revision backward compatability rules therefore also apply to CDR. > > I think that captures the majority of cases, but there may be others > I didn't think of. > > There is also the issue of how to recognize encapsulations - I think > a > CDR version identifier along the lines of what we discussed for the > cached type code proposal will be necessary. I agree that it makes sense to use the extra bits of the byte order byte. But we might also want to think about minor vs. major revisions, if these make sense for CDR. Also, should every GIOP version be a distinct CDR version, or should they be separately identified. Again, I'm becoming more and more opposed to using CDR encapsulations for TypeCodes and Anys (and value types). For non-encapsulated data in a GIOP message stream, the CDR version has been negotiated using the GIOP mechanism. But there is no version negotiation possible for encapsulated data. The scenario of forwarding a parameter as an uninterpreted encapsulation is going to be less and less feasable, so we might as well only use encapsulations where they are absolutely necessary - in tagged profiles, components, and service contexts, which are passed without introspection capability to contexts that might not know of them. -Bob > > Michi. > -- > Michi Henning +61 7 33654310 > DSTC Pty Ltd +61 7 33654311 (fax) > University of Qld 4072 michi@dstc.edu.au > AUSTRALIA > http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 22 Jul 1998 14:03:09 +1000 (EST) From: Michi Henning To: Bob Kukura cc: Jeffrey Mischkinsky , Jonathan Biggar , interop@omg.org, obv-rtf@omg.org Subject: Re: New IDL types On Tue, 21 Jul 1998, Bob Kukura wrote: > I think this supports my position against using encapsulations for Any > values, or for TypeCodes, for that matter. If an ORB keeps an > encapsulation around without interpreting it, it cannot forward it to a > lower versioned ORB than that from which it was recieved without > ensuring it is legal for the lower version. This is just as serious a > problem for TypeCodes, when new TCKinds are introduced, as it is for the > value portion of Anys. Yes. I don't think this means encapsulations are bad as such. However, what *is* bad is that encapsulations do not carry a version that indicates the highest version number of any of the data inside the encapsulation. Assume that encapsulations had a version number for the moment, together with the length count and the byte ordering. The version number could indicate the highest version number of any nested encapsulations. When an ORB wants to embed an older encapsulation in a newer one, it can still do that and simply set the version number of the enclosing encapsulation. That would allow me to determine whether it is safe to forward the encapsulation to lower-version receiver or not without having to completely decode it. [ The tacit assumption is that we will require all ORBs to support all previous versions of CDR forever. ] > I think each profile, component, and service tag definition that uses > encapsulations should state which CDR version is used. If the tag isn't > recognized, it doesn't matter if the encapsulation is an unknown > version. New profiles, components, and service contexts can be defined > to use the CDR version corresponding to the GIOP version in which they > are introduced. If GIOP 1.2 supports value types, tags defined for 1.2, > and not for earlier GIOP version, can use value types. I don't think we > are in trouble yet, since, as far as I know, none of the standard > profile, component, or service bodies contain Anys, TypeCodes, extended > data types, or Value types, so they are all effectively CDR 1.0. Yes. I think that would work. Of course, for long long and the other new IDL types, the damage is done. Just too bad... :-( > The negotiated GIOP version needs to imply the specific CDR version for > the GIOP message streams, including the allowed IDL types. GIOP's minor > revision backward compatability rules therefore also apply to CDR. Agree. > I agree that it makes sense to use the extra bits of the byte order > byte. But we might also want to think about minor vs. major > revisions, > if these make sense for CDR. Also, should every GIOP version be a > distinct CDR version, or should they be separately identified. I think they need to be separately identified, simply because of the scenario I described above. > Again, I'm becoming more and more opposed to using CDR encapsulations > for TypeCodes and Anys (and value types). For non-encapsulated data in > a GIOP message stream, the CDR version has been negotiated using the > GIOP mechanism. But there is no version negotiation possible for > encapsulated data. The scenario of forwarding a parameter as an > uninterpreted encapsulation is going to be less and less feasable, so we > might as well only use encapsulations where they are absolutely > necessary - in tagged profiles, components, and service contexts, which > are passed without introspection capability to contexts that might not > know of them. I do like the idea of hard-wiring the CDR version onto the GIOP version for the reasons you state. It makes things simpler, but also forces dropping of encapsulations, which will make people like Javier scream, I expect ;-) [ And rightfully so, I might add, because it would slow event channels down even more... ] On the other hand, marshaling and protocol messages are really at two completely different levels of abstraction. For example, I see no reason off-hand why GIOP couldn't run on top of a BER marshaling engine. My feeling is that we are getting bitten now simply because GIOP never separated the different abstraction layers in the first place, and completely neglected to do things like add a version number to encapsulations. Now we are paying the price... My gut feeling is that we need GIOP 2.0, and we need clean abstraction layers in it, so marshaling, fragmentation, encapsulation, chunking, location forwarding, and so on are dealt with by orthogonal parts of the overall protocol. Cheers, Michi. -- Michi Henning +61 7 33654310 vDSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: From: Jeffrey Mischkinsky Subject: Re: New IDL types To: kukura@iona.com (Bob Kukura) Date: Wed, 22 Jul 1998 02:14:55 -0700 (PDT) Cc: michi@dstc.edu.au, jon@floorboard.com, interop@omg.org, obv-rtf@omg.org 'Bob Kukura' writes: > > Michi Henning wrote: > > > > Well, I cannot ever send an Any value from a 1.2 sender to a 1.1 > receiver > > unless I have first made sure that none of the encapsulations that > possibly > > may be inside the any contain values that only exist in 1.2. This > not > > only requires me to break open the encapsulation and to decode it > to look > > for 1.2 values, it also means I must be able to do this for both > > byte orders, because an encapsulated value may have different byte > ordering. > > > > At least this much must be explicitly stated. i agree. > > I think this supports my position against using encapsulations for > Any > values, or for TypeCodes, for that matter. If an ORB keeps an > encapsulation around without interpreting it, it cannot forward it > to a > lower versioned ORB than that from which it was recieved without > ensuring it is legal for the lower version. This is just as serious > a > problem for TypeCodes, when new TCKinds are introduced, as it is for > the > value portion of Anys. > > > > > Further, IORs must be restrictied to only contain encapsulations > for 1.1 > > because otherwise an IOR passed to 1.1 receiver may end up > containing > > 1.2 encoded data. > > I think each profile, component, and service tag definition that > uses > encapsulations should state which CDR version is used. If the tag > isn't > recognized, it doesn't matter if the encapsulation is an unknown > version. New profiles, components, and service contexts can be > defined > to use the CDR version corresponding to the GIOP version in which > they > are introduced. If GIOP 1.2 supports value types, tags defined for > 1.2, > and not for earlier GIOP version, can use value types. I don't > think we > are in trouble yet, since, as far as I know, none of the standard > profile, component, or service bodies contain Anys, TypeCodes, > extended > data types, or Value types, so they are all effectively CDR 1.0. I agree. In fact, until you pointed this out, i had always just assumed this was the case. (Probably because it was implicit the original discussions when all this stuff was being define.) We've certainly talked about it in the past during previous interop RTFs. > > > > > In addition, GIOP 1.2 must be specified to support both old and > new > > CDR formats. We also need state that 1.0 and 1.1 cannot be used > with the > > new CDR formats. And we need to state that a 1.2 type code cannot > be sent > > to a 1.1 or 1.0 receiver. > > The negotiated GIOP version needs to imply the specific CDR version > for > the GIOP message streams, including the allowed IDL types. GIOP's > minor > revision backward compatability rules therefore also apply to CDR. agree, again if this is not explicit we should make it so. > > > > > I think that captures the majority of cases, but there may be > others > > I didn't think of. > > > > There is also the issue of how to recognize encapsulations - I > think a > > CDR version identifier along the lines of what we discussed for > the > > cached type code proposal will be necessary. > > I agree that it makes sense to use the extra bits of the byte order > byte. But we might also want to think about minor vs. major > revisions, > if these make sense for CDR. Also, should every GIOP version be a > distinct CDR version, or should they be separately identified. Regardless of the rules we agree on, i think we should certainly define the relationship explicitly. It might be simpler just to say CDR n.m <--> GIOP n.m -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-312-5158 jeffm@visigenic.com +1 650-312-5158 Return-Path: From: Jeffrey Mischkinsky Subject: Re: New IDL types To: michi@dstc.edu.au (Michi Henning) Date: Wed, 22 Jul 1998 02:24:20 -0700 (PDT) Cc: kukura@iona.com, jon@floorboard.com, interop@omg.org, obv-rtf@omg.org 'Michi Henning' writes: > > On Tue, 21 Jul 1998, Bob Kukura wrote: > > > I think each profile, component, and service tag definition that > uses > > encapsulations should state which CDR version is used. If the tag > isn't > > recognized, it doesn't matter if the encapsulation is an unknown > > version. New profiles, components, and service contexts can be > defined > > to use the CDR version corresponding to the GIOP version in which > they > > are introduced. If GIOP 1.2 supports value types, tags defined > for 1.2, > > and not for earlier GIOP version, can use value types. I don't > think we > > are in trouble yet, since, as far as I know, none of the standard > > profile, component, or service bodies contain Anys, TypeCodes, > extended > > data types, or Value types, so they are all effectively CDR 1.0. > > Yes. I think that would work. Of course, for long long and the other > new > IDL types, the damage is done. Just too bad... :-( > We did talk about this during a previous interop RTF, but as i recall didn't take any action. When we were formulating OBV, i insisted that regardless of what we did to marshaling, that the mere fact of adding a new tk_ (and related friends) meant that the protocol version had to be bumped. Since i doubt we'll be able to get this language into 2.3, as as stopgap I think it might be a useful GAP (general architectural principle) for the AB to formally approve. (If someone can writeup some appropriate language.) At least GIOP 1.2 will have all the correct tags, etc. defined. It's 1.1 that is a bit problematic. > > The negotiated GIOP version needs to imply the specific CDR version for > > the GIOP message streams, including the allowed IDL types. GIOP's minor > > revision backward compatability rules therefore also apply to CDR. i agree. > > > My gut feeling is that we need GIOP 2.0, and we need clean abstraction > layers in it, so marshaling, fragmentation, encapsulation, chunking, > location forwarding, and so on are dealt with by orthogonal parts of > the overall protocol. would be nice! jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-312-5158 jeffm@visigenic.com +1 650-312-5158 Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 23 Jul 1998 00:37:20 +1000 (EST) From: Michi Henning Reply-To: Michi Henning To: Jeffrey Mischkinsky cc: interop@omg.org, obv-rtf@omg.org, ab@omg.org Subject: Re: New IDL types On Wed, 22 Jul 1998, Jeffrey Mischkinsky wrote: > > Yes. I think that would work. Of course, for long long and the other new > > IDL types, the damage is done. Just too bad... :-( > > > > We did talk about this during a previous interop RTF, but as i recall > didn't take any action. Right, why bother? After all, who cares that a CORBA 2.2 ORB can no longer reliably interoperate with a CORBA 2.0 or CORBA 2.1 ORB when it comes to sending values of type any... Far more important to add 64-bit integers that most CPU architectures still not support, that have no sensible mappings into a number of target languages, and that leave a large number of ORB environments hanging. minimumCORBA eh? Needs to support all of the IDL types, yes? It's going to be some trick implementing full 64-bit emulation and long double emulation in an embedded environment, not to mention fixed-point types :-( I have asked this question repeatedly in the past. So here it is again, with CC to the AB: Must a CORBA 2.2 compliant ORB support the new IDL types or not? I *really* would like an answer to this question. If the answer is yes, then I am afraid there will be next to no CORBA 2.2 compliant ORBs in the foreseeable future. Of course, there is an easy way out. Just specify that the new types may not be supported in all implementation languages or target architectures. And out the window go language transparency and implementation transparency... Or, specify that in a language without native 64-bit support, the value can be sent and received, but not used for computation. In that case of course, out goes language transparency again, not to mention that the new types might as well not exist for those languages ("What, you want to talk to a server using 64-bit integers from C++ on a 32-bit CPU *AND* on top of that, you want to do computations with those values? Sorry, you'll have to find a different CPU. Or you can always use Java, of course.") Adding the new types also has some other interesting side-effects, other than at the protocol level. For example, we now have a single type any in IDL, but with two different sets of semantics. One kind of any can handle the new types, the other can't, depending on what ORB the software runs :-( And there I was thinking that type any could be used without endangering interoperability... Interesting too that there is no mention of 64-bit integers, long doubles, or fixed-point values in the OMA while there *is* explicit mention of 32-bit integers and ordinary doubles... Seems like the OMA is an irrelevant document these days? > When we were formulating OBV, i insisted that > regardless of what we did to marshaling, that the mere fact of > adding > a new tk_ (and related friends) meant that the protocol version had > to > be bumped. I'm glad to hear it! So now, let's see how we are going to deal with the protocol versioning issues, in particular with respect to encapsulations. And please, such that CORBA 2.3 can reliably communicate with CORBA 2.2 and earlier... Considering that it has taken commercial vendors years to come even close to building vaguely correct IIOP implementations, I would like to express my doubt about vendors' ability to correctly implement whatever rules we concoct. If it takes vendors years to even get IIOP right as it stands today, what are the chances that GIOP 1.2 will have even a remote chance of interoperating in the foreseeable future? But I guess it doesn't matter, as long as we get truncatable values... Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Wed, 22 Jul 1998 23:23:10 PDT Sender: Bill Janssen From: Bill Janssen To: Jeffrey Mischkinsky , Michi Henning Subject: Re: New IDL types CC: interop@omg.org, obv-rtf@omg.org, ab@omg.org References: Excerpts from local.omg: 22-Jul-98 Re: New IDL types Michi Henning@dstc.edu.a (3770*) > Right, why bother? After all, who cares that a CORBA 2.2 ORB can no > longer reliably interoperate with a CORBA 2.0 or CORBA 2.1 ORB when > it > comes to sending values of type any... > Far more important to add 64-bit integers that most CPU architectures > still not support, that have no sensible mappings into a number of target > languages, and that leave a large number of ORB environments hanging. It's the Architecture Board and PTC that passed/recommended a broken submission, not the members of the Interop RTF. Actually, I'm not sure the AB was in effect at that time, so perhaps they can't be blamed for that one. Bill Return-Path: Date: Wed, 22 Jul 1998 23:31:29 PDT Sender: Bill Janssen From: Bill Janssen To: Michi Henning Subject: Re: New IDL types CC: interop@omg.org, obv-rtf@omg.org, ab@omg.org References: Excerpts from local.omg: 22-Jul-98 Re: New IDL types Michi Henning@dstc.edu.a (3770*) > I have asked this question repeatedly in the past. So here it is again, > with CC to the AB: > Must a CORBA 2.2 compliant ORB support the new IDL types or not? > I *really* would like an answer to this question. If the answer is yes, > then I am afraid there will be next to no CORBA 2.2 compliant ORBs in the > foreseeable future. Frankly, I doubt that there are any CORBA 2.x compliant ORBs anywhere, for any value of x. Nor do I believe that there will be any such any time soon (this century :-). I'm confident that between us we could always find some arcane area of the spec that wasn't implemented, or wasn't implemented correctly, or addresses an area that is still inconsistent in the spec. Just think about the arcane complexities of typecodes, fixed types, and unions. Heck, most commercial ORBs don't even seem to implement service context discarding properly. Many do not deal correctly with unknown, but valid, profiles in the object reference. The real question is the measure of non-compliance: what's an acceptable epsilon to be under? Bill Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 23 Jul 1998 16:38:13 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Jeffrey Mischkinsky , interop@omg.org, obv-rtf@omg.org, ab@omg.org Subject: Re: New IDL types On Wed, 22 Jul 1998, Bill Janssen wrote: > Excerpts from local.omg: 22-Jul-98 Re: New IDL types Michi > Henning@dstc.edu.a (3770*) > > > Right, why bother? After all, who cares that a CORBA 2.2 ORB can > no > > longer reliably interoperate with a CORBA 2.0 or CORBA 2.1 ORB > when it > > comes to sending values of type any... > > > Far more important to add 64-bit integers that most CPU > architectures > > still not support, that have no sensible mappings into a number of > target > > languages, and that leave a large number of ORB environments > hanging. > > It's the Architecture Board and PTC that passed/recommended a broken > submission, not the members of the Interop RTF. Actually, I'm not > sure > the AB was in effect at that time, so perhaps they can't be blamed > for > that one. Well, it's not so much about blame, but about the fact that incidents like this are highly embarrassing and not exactly confidence-inspiring. This general attitude of "Let's just toss it in there and fix the problems later." is beginning to do some serious damage. I don't think CORBA can tolerate much more of this without suffering seriously in the market... I don't care all that much about who exactly was responsible. The point is that mistakes like this should not happen at all. It's an attitude problem as much as a procedural one. Playing in the standards arena requires accepting responsibility. When you are tinkering around at the platform level, perfection, correctness, and elegance are more important than in just about any other area of computing. Every little tiny glitch or mistake gets magnified a thousand-fold because thousands of programmers over and over again all end up suffering from the same single glitch or mistake, no matter how innocuous. We have far too many people playing in the OMG who like to play, add features, and get their name on submissions. We have too few people who are prepared to step back and keep things at arm's length for a while, or willing to actually implement something before tossing it in the pot. Instead, a lot of people seem to be confident that they can design feature X so well that there is absolutely no need for the feature to prove itself in implementations first, or, God forbid, in real-life applications. Playing in the standards arena can be a lot of fun and can be very rewarding. Too many people in the OMG are bent on the fun part -- the responsibility that comes along with the fun is conveniently forgotten about in some cases... Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 23 Jul 1998 16:49:22 +1000 (EST) From: Michi Henning To: Bill Janssen cc: interop@omg.org, obv-rtf@omg.org, ab@omg.org Subject: Re: New IDL types On Wed, 22 Jul 1998, Bill Janssen wrote: > Excerpts from local.omg: 22-Jul-98 Re: New IDL types Michi > Henning@dstc.edu.a (3770*) > > > I have asked this question repeatedly in the past. So here it is > again, > > with CC to the AB: > > > Must a CORBA 2.2 compliant ORB support the new IDL types or > not? > > > I *really* would like an answer to this question. If the answer is > yes, > > then I am afraid there will be next to no CORBA 2.2 compliant ORBs > in the > > foreseeable future. > > Frankly, I doubt that there are any CORBA 2.x compliant ORBs > anywhere, > for any value of x. Nor do I believe that there will be any such > any > time soon (this century :-). I'm confident that between us we could > always find some arcane area of the spec that wasn't implemented, or > wasn't implemented correctly, or addresses an area that is still > inconsistent in the spec. I agree. Perfection is unachievable in a system of this level of complexity. > Just think about the arcane complexities of > typecodes, fixed types, and unions. Heck, most commercial ORBs > don't > even seem to implement service context discarding properly. Many do > not > deal correctly with unknown, but valid, profiles in the object > reference. Sure. These are parts that could be done better. However, I am not asking whether the new IDL types are implemented correctly or not for an ORB to be CORBA 2.2 compliant. My question aims at the level below that: Must an ORB claim to support the new IDL types to be CORBA 2.2 compliant (note that I'm not saying anything about correctness here). > The real question is the measure of non-compliance: what's an > acceptable epsilon to be under? OK, let's rephrase the question: Is it tolerable for a 2.2 compliant ORB to not have any support for the new IDL types? Let's be generous, and say that non-support could manifest itself any way it likes, for example by complete ignorance of the new types and failure to compile, or to generate correct code from, IDL definitions that use the new types. Follow-up to the previous question: How will the CORBA branding program address the new IDL types when it comes to certification of an ORB on a 32-bit platform without support for the new IDL types? Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Thu, 23 Jul 1998 00:07:05 PDT Sender: Bill Janssen From: Bill Janssen To: Michi Henning Subject: Re: New IDL types CC: interop@omg.org, obv-rtf@omg.org, ab@omg.org References: Excerpts from direct: 22-Jul-98 Re: New IDL types Michi Henning@dstc.edu.a (2483*) > OK, let's rephrase the question: > Is it tolerable for a 2.2 compliant ORB to not have any support > for the new IDL types? > Let's be generous, and say that non-support could manifest itself any way > it likes, for example by complete ignorance of the new types and failure > to compile, or to generate correct code from, IDL definitions that use > the new types. Sure. I think it's even tolerable for a 2.2-compliant ORB to not support the DII or IR :-). Someone at DSTC ships something they call a CORBA 2.x ORB which doesn't support any of the standard language mappings (didn't supporting at least one of them become a requirement for CORBA Core?). > How will the CORBA branding program address the new IDL types > when it comes to certification of an ORB on a 32-bit platform > without support for the new IDL types? A much more interesting question. A good advertising position might be, ``Our ORB fails only these tests of the CORBA 2.1 branding program: xxx, xxx, xxx. Far fewer failures than any other ORB!''. Bill Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 23 Jul 1998 17:21:07 +1000 (EST) From: Michi Henning To: Bill Janssen cc: interop@omg.org, obv-rtf@omg.org, ab@omg.org Subject: Re: New IDL types On Thu, 23 Jul 1998, Bill Janssen wrote: > Sure. I think it's even tolerable for a 2.2-compliant ORB to not > support the DII or IR :-). Someone at DSTC ships something they > call a > CORBA 2.x ORB which doesn't support any of the standard language > mappings (didn't supporting at least one of them become a > requirement > for CORBA Core?). I think you are right. Thanks for pointing this out. I'll pass it on the appropriate person. > A much more interesting question. A good advertising position might be, > ``Our ORB fails only these tests of the CORBA 2.1 branding program: > xxx, xxx, xxx. Far fewer failures than any other ORB!''. Not a bad idea. At least we would know where we stand then :-( Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Thu, 23 Jul 1998 18:29:44 +0200 From: Martin von Loewis To: michi@dstc.edu.au CC: interop@omg.org Subject: Re: New IDL types References: > Must a CORBA 2.2 compliant ORB support the new IDL types or not? > > I *really* would like an answer to this question. If the answer is yes, > then I am afraid there will be next to no CORBA 2.2 compliant ORBs in the > foreseeable future. Well, there are CORBA implementations that do support all these types, in most of their target languages. > Of course, there is an easy way out. Just specify that the new types > may not be supported in all implementation languages or target > architectures. And out the window go language transparency and > implementation transparency... Are you suggesting that the adopted mappings to some of the languages cannot be implemented, with reasonable effort? Which type, and for which language? > Or, specify that in a language without native 64-bit support, the value > can be sent and received, but not used for computation. This is really out of scope; it is a matter of expressiveness of the target language, not a question of an IDL mapping. If people want to compute with 64 bit integer values, they should use an implementation language that supports it. It will still interoperate with other implementations that mere store the values, because the interface is independent from the implementation. Regards, Martin Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Fri, 24 Jul 1998 06:12:34 +1000 (EST) From: Michi Henning To: Martin von Loewis cc: interop@omg.org Subject: Re: New IDL types On Thu, 23 Jul 1998, Martin von Loewis wrote: > > Must a CORBA 2.2 compliant ORB support the new IDL types or not? > > > > I *really* would like an answer to this question. If the answer is yes, > > then I am afraid there will be next to no CORBA 2.2 compliant ORBs in the > > foreseeable future. > > Well, there are CORBA implementations that do support all these types, > in most of their target languages. I think that's beside the point, and I didn't say above that would be none, but next to none. > > Of course, there is an easy way out. Just specify that the new types > > may not be supported in all implementation languages or target > > architectures. And out the window go language transparency and > > implementation transparency... > > Are you suggesting that the adopted mappings to some of the languages > cannot be implemented, with reasonable effort? Which type, and for > which language? The fixed mapping for C++ falls into that category, or near enough. Jon Biggar has just made a huge effort trying to clean up that mess. > > Or, specify that in a language without native 64-bit support, the value > > can be sent and received, but not used for computation. > > This is really out of scope; it is a matter of expressiveness of the > target language, not a question of an IDL mapping. If people want to > compute with 64 bit integer values, they should use an implementation > language that supports it. It will still interoperate with other > implementations that mere store the values, because the interface is > independent from the implementation. In the days before the new IDL types, every target language had acceptable support for ever IDL type, and every CPU had acceptable support for every IDL type. With the new IDL types, neither is true any longer. Make of that what you will. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html