Issue 3135: valuebox and DynAny (orb_revision) Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com) Nature: Uncategorized Issue Severity: Summary: The DynAny chapter says absolutely nothing about value boxes. Do they fulfill only the base DynAny interface, or the DynValue interface, or do we need a new DynValueBox interface? If the DynValue interface is supposed to be used, do you treat the boxed value as a single member? If so, what is its name? Resolution: Following text changes address the outage raised in this issue as well as the one from issue 3250 Revised Text: 1. Replace the IDL for DynValue in 9.2 with: interface DynValueCommon : DynAny { boolean is_null(); void set_to_null(); void set_to_value(); }; interface DynValue : DynValueCommon { FieldName current_member_name() raises(TypeMismatch, InvalidValue); CORBA::TCKind current_member_kind() raises(TypeMismatch, InvalidValue); NameValuePairSeq get_members() raises(InvalidValue); void set_members(in NameValuePairSeq value) raises(TypeMismatch, InvalidValue); NameDynAnyPairSeq get_members_as_dyn_any() raises(InvalidValue); void set_members_as_dyn_any(in NameDynAnyPairSeq value) raises(TypeMismatch, InvalidValue); }; interface DynValueBox : DynValueCommon { any get_boxed_value() raises(InvalidValue); void set_boxed_value(in any boxed) raises(TypeMismatch); DynAny get_boxed_value_as_dyn_any() raises(InvalidValue); void set_boxed_value_as_dyn_any(in DynAny boxed) raises(TypeMismatch); }; ------------------------------------------------------------------------------ 2. Change the complex type initialization bullet in section 9.2.2 for DynValue from: o For DynValue, the members are initialized as for DynStruct. to: o For DynValue and DynValueBox, initialize to a null value ------------------------------------------------------------------------------ 3. Replace section 9.2.10 with: 9.2.10 The DynValueCommon interface DynValueCommon provides operations supported by both the DynValue and DynValueBox interfaces. interface DynValueCommon : DynAny { boolean is_null(); void set_to_null(); void set_to_value(); }; boolean is_null(); The is_null operation returns TRUE if the DynValueCommon represents a null valuetype. void set_to_null(); The set_to_null() operation changes the representation of a DynValueCommon to a null valuetype. void set_to_value(); If the DynValueCommon represents a null valuetype, then set_to_value() replaces it with a newly constructed value, with its components initialized to default values as in DynAnyFactory::create_dyn_any_from_type_code. If the DynValueCommon represents a non-null valuetype, then this operation has no effect. 9.2.11 The DynValue interface DynValue objects are associated with non-boxed valuetypes. interface DynValue : DynValueCommon { FieldName current_member_name() raises(TypeMismatch, InvalidValue); CORBA::TCKind current_member_kind() raises(TypeMismatch, InvalidValue); NameValuePairSeq get_members() raises(InvalidValue); void set_members(in NameValuePairSeq value) raises(TypeMismatch, InvalidValue); NameDynAnyPairSeq get_members_as_dyn_any() raises(InvalidValue); void set_members_as_dyn_any(in NameDynAnyPairSeq value) raises(TypeMismatch, InvalidValue); }; The DynValue interface can represent both null and non-null valuetypes. For a DynValue representing a non-null valuetype, the DynValue's components comprise the public and private members of the valuetype, including those inherited from concrete base valuetypes, in the order of definition. A DynValue representing a null valuetype has no components and a current position of -1. The remaining operations on the DynValue interface generally have equivalent semantics to the same operations on DynStruct. When invoked on a DynValue representing a null valuetype, get_members and get_members_as_dyn_any raise InvalidValue. When invoked on a DynValue representing a null valuetype, set_members and set_members_as_dyn_any convert the DynValue to a non-null valuetype. Warning: indiscriminantly changing the contents of private valuetype members can cause the valuetype implementation to break by violating internal constraints. Access to private members is provided to support such activities as ORB bridging and debugging and should not be used to arbitrarily violate the encapsulation of the valuetype. 9.2.12 The DynValueBox interface DynValueBox objects are associated with boxed valuetypes. interface DynValueBox : DynValueCommon { any get_boxed_value() raises(InvalidValue); void set_boxed_value(in any boxed) raises(TypeMismatch); DynAny get_boxed_value_as_dyn_any() raises(InvalidValue); void set_boxed_value_as_dyn_any(in DynAny boxed) raises(TypeMismatch); }; The DynValueBox interface can represent both null and non-null valuetypes. For a DynValueBox representing a non-null valuetype, the DynValueBox has a single component of the boxed type. A DynValueBox representing a null valuetype has no components and a current position of -1. any get_boxed_value() raises(InvalidValue); The get_boxed_value operation returns the boxed value as an any. If the DynBoxedValue represents a null valuetype, the operation raises InvalidValue. void set_boxed_value(in any boxed) raises(TypeMismatch); The set_boxed_value replaces the boxed value with the specified value. If the DynBoxedValue represents a null valuetype, it is converted to a non-null value. The get_boxed_value_as_dyn_any and set_boxed_value_as_dyn_any have the same semantics as their any counterparts, but accept and return values of type DynAny instead of any. Actions taken: December 17, 1999: received issue October 6, 2000: closed issue Discussion: End of Annotations:===== X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 17 Dec 1999 10:46:47 -0500 To: issues@omg.org, orb_revision@omg.org From: Steve Vinoski Subject: valuebox and DynAny Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: lA+e9!jWd9, Date: Fri, 17 Dec 1999 14:24:15 -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: issues@omg.org, orb_revision@omg.org Subject: Re: valuebox and DynAny References: <4.1.19991217104252.00ceea40@mail.boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: RPHe98YR!!T9#!!9<(!! Steve Vinoski wrote: > > The DynAny chapter says absolutely nothing about value boxes. Do > they > fulfill only the base DynAny interface, or the DynValue interface, > or do we > need a new DynValueBox interface? If the DynValue interface is > supposed to > be used, do you treat the boxed value as a single member? If so, > what is > its name? Jishnu, I consider this issue as serious as the one I brought up yesterday about the missing TypeCode constant for ValueBase. Without a fix for this, using DynAny for a datatype that is/contains a value box is broken. Steve++ & I have have been iterating over this in private trying to come up with a proposal. Hopefully we can come up with something in a day or two. Of course, any suggestions from the rest of the RTF members is welcome. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 17 Dec 1999 19:15:28 -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 Subject: Re: valuebox and DynAny References: <4.1.19991217104252.00ceea40@mail.boston.amer.iona.com> <385AB80F.FCC3EC52@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^8`!!H)0!!bM9e9^&B!! Jonathan Biggar wrote: > Steve Vinoski wrote: > > > > The DynAny chapter says absolutely nothing about value boxes. Do > they > > fulfill only the base DynAny interface, or the DynValue interface, > or do we > > need a new DynValueBox interface? If the DynValue interface is > supposed to > > be used, do you treat the boxed value as a single member? If so, > what is > > its name? > > Jishnu, I consider this issue as serious as the one I brought up > yesterday about the missing TypeCode constant for ValueBase. > Without a > fix for this, using DynAny for a datatype that is/contains a value > box > is broken. > Steve++ & I have have been iterating over this in private trying to come > up with a proposal. Hopefully we can come up with something in a day or > two. Of course, any suggestions from the rest of the RTF members is > welcome. Nobody has seen what you two have been cooking uptil now. So the earliest this could be put up for vote would be the week of Christmas. I need the entire Christmas week to produce drafts of the Chapters so that we can present the report from this RTF at the January meeting. Would you rather that we delay the presentation of the RTF report to sometime after the January meeting just to fix this one more issue, which we can fix in the next RTF by the end of January anyway? Considering the logistical realities I am going to turn this one down for this RTF. The last vote has been sent out already. This RTF is done as far as sending out votes concerned. What is not already on a vote is not going to be addressed in this RTF. Sorry, 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: <38E13510.D34ECE86@floorboard.com> Date: Tue, 28 Mar 2000 14:41:20 -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: orb_revision@omg.org Subject: Proposal for issues 3135 and 3250 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +&f!!~8@e9[dUd9$!3e9 Issue 3135: valuebox and DynAny Issue 3250: Null valuetypes not supported by DynValue [Thanks to Steve, Michi, and Mark, for ideas and much cribbed text. :-)] Proposal for Issues 3135 and 3250: 1. Replace the IDL for DynValue in 9.2 with: interface DynValueCommon : DynAny { boolean is_null(); void set_to_null(); void set_to_value(); }; interface DynValue : DynValueCommon { FieldName current_member_name() raises(TypeMismatch, InvalidValue); CORBA::TCKind current_member_kind() raises(TypeMismatch, InvalidValue); NameValuePairSeq get_members(); void set_members(in NameValuePairSeq value) raises(TypeMismatch, InvalidValue); NameDynAnyPairSeq get_members_as_dyn_any(); void set_members_as_dyn_any(in NameDynAnyPairSeq value) raises(TypeMismatch, InvalidValue); }; interface DynValueBox : DynValueCommon { any get_boxed_value(); void set_boxed_value(in any boxed) raises(TypeMismatch); DynAny get_boxed_value_as_dyn_any(); void set_boxed_value_as_dyn_any(in DynAny boxed) raises(TypeMismatch); }; ------------------------------------------------------------------------------ 2. Replace section 9.2.10 with: 9.2.10 The DynValueCommon interface DynValueCommon provides operations supported by both the DynValue and DynValueBox interfaces. [Insert appropriate IDL from above here.] boolean is_null(); The is_null operation returns TRUE if the DynValueCommon represents a null valuetype. void set_to_null(); The set_to_null() operation changes the representation of a DynValueCommon to a null valuetype. void set_to_value(); If the DynValueCommon represents a null valuetype, then set_to_value() replaces it with a newly constructed value, initialized exactly as if DynAnyFactory::create_dyn_any_from_type_code had been invoked. If the DynValueCommon represents a non-null valuetype, then this operation has no effect. 9.2.11 The DynValue interface DynValue objects are associated with non-boxed valuetypes. [Insert appropriate IDL from above here.] The DynValue interface can represent both null and non-null valuetypes. For a DynValue representing a non-null valuetype, the DynValue's components comprise the public and private members of the valuetype, including those inherited from concrete base valuetypes, in the order of definition. A DynValue representing a null valuetype has no components and a current position of -1. The remaining operations on the DynValue interface have equivalent semantics to DynStruct. When invoked on a DynValue representing a null valuetype, get_members and get_members_as_dyn_any return an empty sequence. 9.2.12 The DynValueBox interface DynValueBox objects are associated with boxed valuetypes. [Insert appropriate IDL from above here.] any get_boxed_value() raises(InvalidValue); The get_boxed_value operation returns the boxed value as an any. If the DynBoxedValue represents a null valuetype, the operation raises InvalidValue. void set_boxed_value(in any boxed) raises(TypeMismatch, InvalidValue); The set_boxed_value replaces the boxed value with the specified value. If the DynBoxedValue represents a null valuetype, the operation raises InvalidValue. The get_boxed_value_as_dyn_any and set_boxed_value_as_dyn_any have the same semantics as their any counterparts, but accept and return values of type DynAny instead of any. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: mark@192.168.1.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 28 Mar 2000 16:10:03 -0800 To: Jonathan Biggar , orb_revision@omg.org From: Mark Spruiell Subject: Re: Proposal for issues 3135 and 3250 In-Reply-To: <38E13510.D34ECE86@floorboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: ]3`d90dOe9l#\!!d^a!! Jon, See comments below. At 02:41 PM 3/28/00, Jonathan Biggar wrote: >[...] >interface DynValue : DynValueCommon { > > FieldName current_member_name() > raises(TypeMismatch, InvalidValue); > > CORBA::TCKind current_member_kind() > raises(TypeMismatch, InvalidValue); > > NameValuePairSeq get_members(); > > void set_members(in NameValuePairSeq value) > raises(TypeMismatch, InvalidValue); > > NameDynAnyPairSeq get_members_as_dyn_any(); > > void set_members_as_dyn_any(in NameDynAnyPairSeq value) > raises(TypeMismatch, InvalidValue); > >}; > >interface DynValueBox : DynValueCommon { > any get_boxed_value(); > > void set_boxed_value(in any boxed) raises(TypeMismatch); > > DynAny get_boxed_value_as_dyn_any(); > > void set_boxed_value_as_dyn_any(in DynAny boxed) > raises(TypeMismatch); > >}; >[...] >9.2.12 The DynValueBox interface > >DynValueBox objects are associated with boxed valuetypes. Note that the IDL shown below doesn't exactly match the IDL above (specifically, the exceptions are different). >[Insert appropriate IDL from above here.] > > any get_boxed_value() > raises(InvalidValue); > >The get_boxed_value operation returns the boxed value as an any. If >the DynBoxedValue represents a null valuetype, the operation raises >InvalidValue. > > void set_boxed_value(in any boxed) > raises(TypeMismatch, InvalidValue); > >The set_boxed_value replaces the boxed value with the specified value. >If the DynBoxedValue represents a null valuetype, the operation raises >InvalidValue. I think we should be striving for consistent semantics between DynValue and DynValueBox. Let's concentrate on the null-value semantics for the moment. For the get_* operations, there are two choices: 1) Raise an exception 2) Succeed, but return a value that indicates a null value In my original proposal for modifying DynValue to accommodate null values, I opted for #2, i.e., return an empty sequence. This was done primarily to avoid changing the IDL and to maintain similarity with DynStruct. However, that strategy gets increasingly awkward for DynValueBox, therefore raising an exception seems like the cleaner approach. The user can always avoid the exception by calling is_null. For the set_* operations, again there are two choices: 1) Raise an exception 2) Implicitly convert to a non-null value, then proceed The intent of my original proposal was #2, which is more convenient in that it does not require the user to first call is_null and set_to_value before modifying the value. In summary, I'm suggesting that your IDL be modified to add InvalidValue to the DynValue::get_* operations, and to remove InvalidValue from the DynValueBox::set_* operations (with corresponding changes to the text). Take care, Mark -- Mark E. Spruiell Object Oriented Concepts, Inc. mes@ooc.com * http://www.ooc.com * 1-978-439-9285 x 247 Sender: jbiggar@corvette.floorboard.com Message-ID: <38E15577.E8922FD1@floorboard.com> Date: Tue, 28 Mar 2000 16:59:35 -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: Mark Spruiell CC: orb_revision@omg.org Subject: Re: Proposal for issues 3135 and 3250 References: <4.3.2.20000328145737.01e98310@192.168.1.1> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,0U!!jfUd9Zlgd9i-#!! Mark Spruiell wrote: > I think we should be striving for consistent semantics between > DynValue > and DynValueBox. Let's concentrate on the null-value semantics for > the > moment. Yeah, I noticed the inconsistency just before I sent it out. I decided to let someone else point it out. :-) > In summary, I'm suggesting that your IDL be modified to add > InvalidValue to the DynValue::get_* operations, and to remove > InvalidValue from the DynValueBox::set_* operations (with > corresponding changes to the text). That's reasonable. I'll gather any more comments over the next couple of days and repost the "final" version on Friday. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: mark@192.168.1.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 29 Mar 2000 06:11:55 -0800 To: Jonathan Biggar , orb_revision@omg.org From: Mark Spruiell Subject: Re: Proposal for issues 3135 and 3250 In-Reply-To: <38E13510.D34ECE86@floorboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: E=a!!*>?e9)Vj!!X@X!! Jon, At 02:41 PM 3/28/00, Jonathan Biggar wrote: >9.2.12 The DynValueBox interface > >DynValueBox objects are associated with boxed valuetypes. A DynValueBox has a single component, right? I think that should be stated. Also, I wonder if we should change the initialization semantics for DynValue. Currently, section 9.2.2 states that a DynValue is initialized like a DynStruct. In other words, the DynValue is initialized to a non-null value with its components set to default values. However, I think things would hang together better if a DynValue was initially created to represent a null value. This is especially useful for recursive valuetype TypeCodes. DynValueBox can still be initialized with a default boxed value. And this fact should be mentioned in 9.2.2. Take care, Mark -- Mark E. Spruiell Object Oriented Concepts, Inc. mes@ooc.com * http://www.ooc.com * 1-978-439-9285 x 247 Sender: jbiggar@corvette.floorboard.com Message-ID: <38E29B89.C6656A0E@floorboard.com> Date: Wed, 29 Mar 2000 16:10:49 -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: Mark Spruiell CC: orb_revision@omg.org Subject: Re: Proposal for issues 3135 and 3250 References: <4.3.2.20000329055919.01e9b950@192.168.1.1> <4.3.2.20000329154840.01eb2ce0@192.168.1.1> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \~Q!!:;B!!K]#!!8lQ!! Mark Spruiell wrote: > >I'm afraid I disagree. The current semantic for DynValue is to > >initialize to a non-null value, so changing this would break code. > >However, all is not lost, since this applies only to DynValue > objects > >that are constructed from the DynAnyFactory interface. A valuetype > >member will still be initialized to a null value, so: > > > >// IDL > >valuetype V { > > public V member; > >}; > > > >won't immediately cause an infinite recursion when constructing a > >DynValue for it. > > I don't see anything in the spec that says valuetype members are > initialized to null. The spec simply says that members are > initialized to their default values, and the 'default value' for > a valuetype is for all of its members to be initialized to their > default values. I've always thought of member initialization as > the result of invoking the factory operation on each member. That > would no longer be true for the special case of valuetypes, if > what you said is true. > > I agree that breaking existing code should be avoided, but we > would be breaking code that depends on a broken spec. :) > > There is also the issue of performance. While users of DynAny > are already incurring a performance penalty, should we add to > it by forcing every DynValue to have its members initialized > when the user might want a null value? > > It seems cleaner to me to specify that the default value for a > valuetype is null. This addresses the performance and recursion > issues, but admittedly breaks existing code. Oops, you are right, but I still disagree. The spec should be tweeked so that valuetype members of complex types (struct, union, sequence, array, valuetype) are initialized to null, but when a DynValue is constructed using DynAnyFactory, it is initialized to a non-null value. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@corvette.floorboard.com Message-ID: <38E29485.1EE76260@floorboard.com> Date: Wed, 29 Mar 2000 15:40:53 -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: Mark Spruiell CC: orb_revision@omg.org Subject: Re: Proposal for issues 3135 and 3250 References: <4.3.2.20000329055919.01e9b950@192.168.1.1> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 52Me97JY!!;'-!!:@7e9 Mark Spruiell wrote: > >9.2.12 The DynValueBox interface > > > >DynValueBox objects are associated with boxed valuetypes. > > A DynValueBox has a single component, right? I think that should > be stated. Good point. I'll add that. > Also, I wonder if we should change the initialization semantics > for DynValue. Currently, section 9.2.2 states that a DynValue is > initialized like a DynStruct. In other words, the DynValue is > initialized to a non-null value with its components set > to default values. > > However, I think things would hang together better if a DynValue > was initially created to represent a null value. This is > especially useful for recursive valuetype TypeCodes. I'm afraid I disagree. The current semantic for DynValue is to initialize to a non-null value, so changing this would break code. However, all is not lost, since this applies only to DynValue objects that are constructed from the DynAnyFactory interface. A valuetype member will still be initialized to a null value, so: // IDL valuetype V { public V member; }; won't immediately cause an infinite recursion when constructing a DynValue for it. > DynValueBox can still be initialized with a default boxed value. > And this fact should be mentioned in 9.2.2. Again, good point. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: mark@192.168.1.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 29 Mar 2000 16:00:54 -0800 To: Jonathan Biggar From: Mark Spruiell Subject: Re: Proposal for issues 3135 and 3250 Cc: orb_revision@omg.org In-Reply-To: <38E29485.1EE76260@floorboard.com> References: <4.3.2.20000329055919.01e9b950@192.168.1.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: RBf!!m5'!![B`d9K9=!! Hi Jon, At 03:40 PM 3/29/00, Jonathan Biggar wrote: > > Also, I wonder if we should change the initialization semantics > > for DynValue. Currently, section 9.2.2 states that a DynValue is > > initialized like a DynStruct. In other words, the DynValue is > > initialized to a non-null value with its components set > > to default values. > > > > However, I think things would hang together better if a DynValue > > was initially created to represent a null value. This is > > especially useful for recursive valuetype TypeCodes. > >I'm afraid I disagree. The current semantic for DynValue is to >initialize to a non-null value, so changing this would break code. >However, all is not lost, since this applies only to DynValue objects >that are constructed from the DynAnyFactory interface. A valuetype >member will still be initialized to a null value, so: > >// IDL >valuetype V { > public V member; >}; > >won't immediately cause an infinite recursion when constructing a >DynValue for it. I don't see anything in the spec that says valuetype members are initialized to null. The spec simply says that members are initialized to their default values, and the 'default value' for a valuetype is for all of its members to be initialized to their default values. I've always thought of member initialization as the result of invoking the factory operation on each member. That would no longer be true for the special case of valuetypes, if what you said is true. I agree that breaking existing code should be avoided, but we would be breaking code that depends on a broken spec. :) There is also the issue of performance. While users of DynAny are already incurring a performance penalty, should we add to it by forcing every DynValue to have its members initialized when the user might want a null value? It seems cleaner to me to specify that the default value for a valuetype is null. This addresses the performance and recursion issues, but admittedly breaks existing code. Take care, Mark -- Mark E. Spruiell Object Oriented Concepts, Inc. mes@ooc.com * http://www.ooc.com * 1-978-439-9285 x 247 Sender: jbiggar@corvette.floorboard.com Message-ID: <38E53CFA.D3AE4EF9@floorboard.com> Date: Fri, 31 Mar 2000 16:04: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: orb_revision@omg.org Subject: Revised proposal for issues 3135 and 3250 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: L\>!!W;a!!ZUg!!V:g!! Issue 3135: valuebox and DynAny Issue 3250: Null valuetypes not supported by DynValue [Mark S and I have a disagreement over how DynValue and DynValueBox should be initialized via the DynAnyFactory operations. He believes that they should be initialized to a null value, since it is more consistent and better performing. I agree with the sentiment, but I think it is better to initialize top level DynValue & DynValueBox to non-null values, but initialize members of these types as null values in order to avoid breaking code. Since I've written the proposal, the current draft has my preference. :-) Now is the time to chime in on your opinions.] Proposal for Issues 3135 and 3250: 1. Replace the IDL for DynValue in 9.2 with: interface DynValueCommon : DynAny { boolean is_null(); void set_to_null(); void set_to_value(); }; interface DynValue : DynValueCommon { FieldName current_member_name() raises(TypeMismatch, InvalidValue); CORBA::TCKind current_member_kind() raises(TypeMismatch, InvalidValue); NameValuePairSeq get_members() raises(InvalidValue); void set_members(in NameValuePairSeq value) raises(TypeMismatch, InvalidValue); NameDynAnyPairSeq get_members_as_dyn_any() raises(InvalidValue); void set_members_as_dyn_any(in NameDynAnyPairSeq value) raises(TypeMismatch, InvalidValue); }; interface DynValueBox : DynValueCommon { any get_boxed_value() raises(InvalidValue); void set_boxed_value(in any boxed) raises(TypeMismatch); DynAny get_boxed_value_as_dyn_any() raises(InvalidValue); void set_boxed_value_as_dyn_any(in DynAny boxed) raises(TypeMismatch); }; ------------------------------------------------------------------------------ 2. Add a new basic type initialization bullet in section 9.2.2: o null for valuetypes ------------------------------------------------------------------------------ 3. Change the complex type initialization bullet in section 9.2.2 for DynValue from: o For DynValue, the members are initialized as for DynStruct. to: o For DynValue, initialize to a non-null value and recursively initialize each state member o For DynValueBox, initialize to a non-null value and recursively initialize the boxed type. ------------------------------------------------------------------------------ 4. Replace section 9.2.10 with: 9.2.10 The DynValueCommon interface DynValueCommon provides operations supported by both the DynValue and DynValueBox interfaces. [Insert appropriate IDL from above here.] boolean is_null(); The is_null operation returns TRUE if the DynValueCommon represents a null valuetype. void set_to_null(); The set_to_null() operation changes the representation of a DynValueCommon to a null valuetype. void set_to_value(); If the DynValueCommon represents a null valuetype, then set_to_value() replaces it with a newly constructed value, initialized exactly as if DynAnyFactory::create_dyn_any_from_type_code had been invoked. If the DynValueCommon represents a non-null valuetype, then this operation has no effect. 9.2.11 The DynValue interface DynValue objects are associated with non-boxed valuetypes. [Insert appropriate IDL from above here.] The DynValue interface can represent both null and non-null valuetypes. For a DynValue representing a non-null valuetype, the DynValue's components comprise the public and private members of the valuetype, including those inherited from concrete base valuetypes, in the order of definition. A DynValue representing a null valuetype has no components and a current position of -1. The remaining operations on the DynValue interface generally have equivalent semantics to the same operations on DynStruct. When invoked on a DynValue representing a null valuetype, get_members and get_members_as_dyn_any raise InvalidValue. When invoked on a DynValue representing a null valuetype, set_members and set_members_as_dyn_any convert the DynValue to a non-null valuetype. 9.2.12 The DynValueBox interface DynValueBox objects are associated with boxed valuetypes. [Insert appropriate IDL from above here.] The DynValueBox interface can represent both null and non-null valuetypes. For a DynValueBox representing a non-null valuetype, the DynValueBox has a single component of the boxed type. A DynValueBox representing a null valuetype has no components and a current position of -1. any get_boxed_value() raises(InvalidValue); The get_boxed_value operation returns the boxed value as an any. If the DynBoxedValue represents a null valuetype, the operation raises InvalidValue. void set_boxed_value(in any boxed) raises(TypeMismatch); The set_boxed_value replaces the boxed value with the specified value. If the DynBoxedValue represents a null valuetype, it is converted to a non-null value. The get_boxed_value_as_dyn_any and set_boxed_value_as_dyn_any have the same semantics as their any counterparts, but accept and return values of type DynAny instead of any. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: mark@192.168.1.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sun, 02 Apr 2000 14:40:01 -0800 To: Jonathan Biggar , orb_revision@omg.org From: Mark Spruiell Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38E53CFA.D3AE4EF9@floorboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: heG!!KN#e9H8Ae9`e8!! Hi Jon, One more rebuttal... :) At 04:04 PM 3/31/00, Jonathan Biggar wrote: >Issue 3135: valuebox and DynAny >Issue 3250: Null valuetypes not supported by DynValue > >[Mark S and I have a disagreement over how DynValue and DynValueBox >should be initialized via the DynAnyFactory operations. He believes >that they should be initialized to a null value, since it is more >consistent and better performing. I agree with the sentiment, but I >think it is better to initialize top level DynValue & DynValueBox to >non-null values, but initialize members of these types as null values in >order to avoid breaking code. I would argue that this proposal already breaks code. By changing exception specifications on operations defined in 2.3, existing code in languages which perform strict exception checking (like Java) will no longer compile using the new IDL. Furthermore, by adding an exception to get_members(), for example, an unmodified C++ application may crash at runtime with an uncaught exception. Since the DynValue specification in 2.3 is rather incomplete (no offense, Michi ;), we should take advantage of this opportunity to get it right. If the consensus is that valuetypes should always be initialized to null, I don't think backward compatibility should prevent us from specifying that. >2. Add a new basic type initialization bullet in section 9.2.2: > >o null for valuetypes That list is describing the default values for basic types, not member types, and it seems confusing to add valuetypes to a list of basic types. Anyway, I'm probably splitting hairs. If the proposal is adopted as-is, that paragraph may need some wordsmithing. 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, 3 Apr 2000 08:56:06 +1000 (EST) From: Michi Henning To: Mark Spruiell cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <4.3.2.20000402133610.00c788d0@192.168.1.1> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 7VMe9Qdgd95&Zd9`08!! On Sun, 2 Apr 2000, Mark Spruiell wrote: > I would argue that this proposal already breaks code. By changing > exception specifications on operations defined in 2.3, existing code > in languages which perform strict exception checking (like Java) > will > no longer compile using the new IDL. > > Furthermore, by adding an exception to get_members(), for example, > an unmodified C++ application may crash at runtime with an uncaught > exception. I agree. > Since the DynValue specification in 2.3 is rather incomplete (no offense, > Michi ;), None take ;-) > we should take advantage of this opportunity to get it right. > If the consensus is that valuetypes should always be initialized to > null, > I don't think backward compatibility should prevent us from > specifying > that. My feeling is that initialization to null is more intuitive and makes sense, so I would prefer that approach. 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 Date: Mon, 03 Apr 2000 09:12:52 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <38E53CFA.D3AE4EF9@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: V-F!!g/&e9/J@e9hdkd9 Jon, Jonathan Biggar wrote: > > Issue 3135: valuebox and DynAny > Issue 3250: Null valuetypes not supported by DynValue > > [Mark S and I have a disagreement over how DynValue and DynValueBox > should be initialized via the DynAnyFactory operations. He believes > that they should be initialized to a null value, since it is more > consistent and better performing. I agree with the sentiment, but I > think it is better to initialize top level DynValue & DynValueBox to > non-null values, but initialize members of these types as null > values in > order to avoid breaking code. > In the original specification of DynValue, it was stated that these > could only be created from an existing valuetype, not created from scratch. > This was to ensure that no valuetype could be created whose state failed to satisfy the type invariant for the valuetype implementation. For the > same reason, it was stated that the DynValue operations could only be used > to access the state of public data members. This came up again later in RTF discussions, and these rules were confirmed. I believe this means that DynValue must be initialized to null when created from a TypeCode. See other comments below. Simon > Since I've written the proposal, the current draft has my preference. > :-) Now is the time to chime in on your opinions.] > > Proposal for Issues 3135 and 3250: > > 1. Replace the IDL for DynValue in 9.2 with: > > interface DynValueCommon : DynAny { > > boolean is_null(); > > void set_to_null(); > > void set_to_value(); > > }; > > interface DynValue : DynValueCommon { > > FieldName current_member_name() > raises(TypeMismatch, InvalidValue); > > CORBA::TCKind current_member_kind() > raises(TypeMismatch, InvalidValue); > > NameValuePairSeq get_members() > raises(InvalidValue); > > void set_members(in NameValuePairSeq value) > raises(TypeMismatch, InvalidValue); > > NameDynAnyPairSeq get_members_as_dyn_any() > raises(InvalidValue); > > void set_members_as_dyn_any(in NameDynAnyPairSeq value) > raises(TypeMismatch, InvalidValue); > > }; > I don't think it is valid to change the inheritance hierarchy of an existing type, because of versioning compatibility issues. This introduces a new base interface DynValueCommon for DynValue. To do this, I think it would be necessary to deprecate the old DynValue class and create a replacement that has this base interface. > interface DynValueBox : DynValueCommon { > any get_boxed_value() > raises(InvalidValue); > > void set_boxed_value(in any boxed) raises(TypeMismatch); > > DynAny get_boxed_value_as_dyn_any() > raises(InvalidValue); > > void set_boxed_value_as_dyn_any(in DynAny boxed) > raises(TypeMismatch); > > }; > > > ------------------------------------------------------------------------------ > 2. Add a new basic type initialization bullet in section 9.2.2: > > o null for valuetypes > You cannot have valuetypes listed under basic types here and also > under complex types below, especially not with different semantics. I > suggest deleting this bullet and changing the DynValue one to initialize to a null value. > ------------------------------------------------------------------------------ > 3. Change the complex type initialization bullet in section 9.2.2 for > DynValue from: > > o For DynValue, the members are initialized as for DynStruct. > > to: > > o For DynValue, initialize to a non-null value and recursively > initialize each state member > > o For DynValueBox, initialize to a non-null value and recursively > initialize the boxed type. > Should initialize both to null. > ------------------------------------------------------------------------------ > 4. Replace section 9.2.10 with: > > 9.2.10 The DynValueCommon interface > > DynValueCommon provides operations supported by both the DynValue and > DynValueBox interfaces. > > [Insert appropriate IDL from above here.] > > boolean is_null(); > > The is_null operation returns TRUE if the DynValueCommon represents a > null valuetype. > > void set_to_null(); > > The set_to_null() operation changes the representation of a > DynValueCommon to a null valuetype. > > void set_to_value(); > > If the DynValueCommon represents a null valuetype, then set_to_value() > replaces it with a newly constructed value, initialized exactly as if > DynAnyFactory::create_dyn_any_from_type_code had been invoked. If the > DynValueCommon represents a non-null valuetype, then this operation has > no effect. > This default initialization should not be allowed. Instead, the set_to_value() operation should take an actual valuetype as a parameter. > 9.2.11 The DynValue interface > > DynValue objects are associated with non-boxed valuetypes. > > [Insert appropriate IDL from above here.] > > The DynValue interface can represent both null and non-null > valuetypes. > For a DynValue representing a non-null valuetype, the DynValue's > components comprise the public and private members of the valuetype, > including those inherited from concrete base valuetypes, in the > order of > definition. A DynValue representing a null valuetype has no > components > and a current position of -1. > Only public members should be exposed. Private members are part of > the internal state of a valuetype implementation and should not be visible to other code. > The remaining operations on the DynValue interface generally have > equivalent semantics to the same operations on DynStruct. When > invoked > on a DynValue representing a null valuetype, get_members and > get_members_as_dyn_any raise InvalidValue. When invoked on a > DynValue > representing a null valuetype, set_members and > set_members_as_dyn_any > convert the DynValue to a non-null > valuetype. > > 9.2.12 The DynValueBox interface > > DynValueBox objects are associated with boxed valuetypes. > > [Insert appropriate IDL from above here.] > > The DynValueBox interface can represent both null and non-null > valuetypes. For a DynValueBox representing a non-null valuetype, the > DynValueBox has a single component of the boxed type. A DynValueBox > representing a null valuetype has no components and a current > position > of -1. > > any get_boxed_value() > raises(InvalidValue); > > The get_boxed_value operation returns the boxed value as an any. If > the > DynBoxedValue represents a null valuetype, the operation raises > InvalidValue. > > void set_boxed_value(in any boxed) > raises(TypeMismatch); > > The set_boxed_value replaces the boxed value with the specified > value. > If the DynBoxedValue represents a null valuetype, it is converted to > a > non-null value. > > The get_boxed_value_as_dyn_any and set_boxed_value_as_dyn_any have > the > same semantics as their any counterparts, but accept and return > values > of type DynAny instead of any. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- 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 Subject: RE: Revised proposal for issues 3135 and 3250 Date: Mon, 3 Apr 2000 08:34:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: $F4!!%C=!!##ld9?)2!! I would prefer initialization to null. Paul > -----Original Message----- > From: Jonathan Biggar [mailto:jon@floorboard.com] > Sent: Friday, March 31, 2000 7:04 PM > To: orb_revision@omg.org > Subject: Revised proposal for issues 3135 and 3250 > > > Issue 3135: valuebox and DynAny > Issue 3250: Null valuetypes not supported by DynValue > > [Mark S and I have a disagreement over how DynValue and DynValueBox > should be initialized via the DynAnyFactory operations. He believes > that they should be initialized to a null value, since it is more > consistent and better performing. I agree with the sentiment, but I > think it is better to initialize top level DynValue & DynValueBox to > non-null values, but initialize members of these types as > null values in > order to avoid breaking code. > > Since I've written the proposal, the current draft has my > preference. > :-) Now is the time to chime in on your opinions.] > > Proposal for Issues 3135 and 3250: > > 1. Replace the IDL for DynValue in 9.2 with: > > interface DynValueCommon : DynAny { > > boolean is_null(); > > void set_to_null(); > > void set_to_value(); > > }; > > interface DynValue : DynValueCommon { > > FieldName current_member_name() > raises(TypeMismatch, InvalidValue); > > CORBA::TCKind current_member_kind() > raises(TypeMismatch, InvalidValue); > > NameValuePairSeq get_members() > raises(InvalidValue); > > void set_members(in NameValuePairSeq value) > raises(TypeMismatch, InvalidValue); > > NameDynAnyPairSeq get_members_as_dyn_any() > raises(InvalidValue); > > void set_members_as_dyn_any(in NameDynAnyPairSeq value) > raises(TypeMismatch, InvalidValue); > > }; > > interface DynValueBox : DynValueCommon { > any get_boxed_value() > raises(InvalidValue); > > void set_boxed_value(in any boxed) raises(TypeMismatch); > > DynAny get_boxed_value_as_dyn_any() > raises(InvalidValue); > > void set_boxed_value_as_dyn_any(in DynAny boxed) > raises(TypeMismatch); > > }; > > -------------------------------------------------------------- > ---------------- > 2. Add a new basic type initialization bullet in section 9.2.2: > > o null for valuetypes > > -------------------------------------------------------------- > ---------------- > 3. Change the complex type initialization bullet in section 9.2.2 > for > DynValue from: > > o For DynValue, the members are initialized as for DynStruct. > > to: > > o For DynValue, initialize to a non-null value and recursively > initialize each state member > > o For DynValueBox, initialize to a non-null value and recursively > initialize the boxed type. > > -------------------------------------------------------------- > ---------------- > 4. Replace section 9.2.10 with: > > 9.2.10 The DynValueCommon interface > > DynValueCommon provides operations supported by both the DynValue > and > DynValueBox interfaces. > > [Insert appropriate IDL from above here.] > > boolean is_null(); > > The is_null operation returns TRUE if the DynValueCommon represents > a > null valuetype. > > void set_to_null(); > > The set_to_null() operation changes the representation of a > DynValueCommon to a null valuetype. > > void set_to_value(); > > If the DynValueCommon represents a null valuetype, then > set_to_value() > replaces it with a newly constructed value, initialized exactly as > if > DynAnyFactory::create_dyn_any_from_type_code had been invoked. If > the > DynValueCommon represents a non-null valuetype, then this > operation has > no effect. > > 9.2.11 The DynValue interface > > DynValue objects are associated with non-boxed valuetypes. > > [Insert appropriate IDL from above here.] > > The DynValue interface can represent both null and non-null > valuetypes. > For a DynValue representing a non-null valuetype, the DynValue's > components comprise the public and private members of the valuetype, > including those inherited from concrete base valuetypes, in > the order of > definition. A DynValue representing a null valuetype has no > components > and a current position of -1. > > The remaining operations on the DynValue interface generally have > equivalent semantics to the same operations on DynStruct. > When invoked > on a DynValue representing a null valuetype, get_members and > get_members_as_dyn_any raise InvalidValue. When invoked on a > DynValue > representing a null valuetype, set_members and > set_members_as_dyn_any > convert the DynValue to a non-null > valuetype. > > 9.2.12 The DynValueBox interface > > DynValueBox objects are associated with boxed valuetypes. > > [Insert appropriate IDL from above here.] > > The DynValueBox interface can represent both null and non-null > valuetypes. For a DynValueBox representing a non-null valuetype, the > DynValueBox has a single component of the boxed type. A DynValueBox > representing a null valuetype has no components and a current > position > of -1. > > any get_boxed_value() > raises(InvalidValue); > > The get_boxed_value operation returns the boxed value as an > any. If the > DynBoxedValue represents a null valuetype, the operation raises > InvalidValue. > > void set_boxed_value(in any boxed) > raises(TypeMismatch); > > The set_boxed_value replaces the boxed value with the specified > value. > If the DynBoxedValue represents a null valuetype, it is converted to > a > non-null value. > > The get_boxed_value_as_dyn_any and set_boxed_value_as_dyn_any have > the > same semantics as their any counterparts, but accept and return > values > of type DynAny instead of any. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > Sender: jbiggar@corvette.floorboard.com Message-ID: <38EE4371.679B2DC7@floorboard.com> Date: Fri, 07 Apr 2000 13:22:10 -0700 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: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <38E53CFA.D3AE4EF9@floorboard.com> > <38E85284.A5DF4BAB@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $SJe93%!"!K9Je9g?8e9 Simon Nash wrote: > > Jon, > > Jonathan Biggar wrote: > > > > Issue 3135: valuebox and DynAny > > Issue 3250: Null valuetypes not supported by DynValue > > > > [Mark S and I have a disagreement over how DynValue and > DynValueBox > > should be initialized via the DynAnyFactory operations. He > believes > > that they should be initialized to a null value, since it is more > > consistent and better performing. I agree with the sentiment, but > I > > think it is better to initialize top level DynValue & DynValueBox > to > > non-null values, but initialize members of these types as null > values in > > order to avoid breaking code. > > > In the original specification of DynValue, it was stated that these > could > only be created from an existing valuetype, not created from > scratch. This > was to ensure that no valuetype could be created whose state failed > to > satisfy the type invariant for the valuetype implementation. For > the same > reason, it was stated that the DynValue operations could only be > used to > access the state of public data members. When Michi reworked DynAny, we discussed these rules for valuetypes and decided that they weren't workable. If you can't access private state members from DynValue, then it is impossible to construct a consistent valuetype that has private state members. I find this restriction would be much worse than the hole that is opened up to allow access to the private members. > This came up again later in RTF discussions, and these rules were confirmed. And then replaced by later discussion when Michi reworked DynAny. > I don't think it is valid to change the inheritance hierarchy of an existing > type, because of versioning compatibility issues. This introduces a new base > interface DynValueCommon for DynValue. To do this, I think it would be > necessary to deprecate the old DynValue class and create a replacement that > has this base interface. Care to explain the perceived problem in more detail? The change effectively only adds new operations to the class. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@corvette.floorboard.com Message-ID: <38EE44A3.B76B01D1@floorboard.com> Date: Fri, 07 Apr 2000 13:27:15 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Second revision of proposal for issues 3135 and 3250 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0!!"=De9 Issue 3135: valuebox and DynAny Issue 3250: Null valuetypes not supported by DynValue [Ok, since I've been outvoted 3 to 1 in a straw poll, I'll change DynValue to initialze to a null valuetype. With that, this proposal is ready for a vote.] Proposal for Issues 3135 and 3250: 1. Replace the IDL for DynValue in 9.2 with: interface DynValueCommon : DynAny { boolean is_null(); void set_to_null(); void set_to_value(); }; interface DynValue : DynValueCommon { FieldName current_member_name() raises(TypeMismatch, InvalidValue); CORBA::TCKind current_member_kind() raises(TypeMismatch, InvalidValue); NameValuePairSeq get_members() raises(InvalidValue); void set_members(in NameValuePairSeq value) raises(TypeMismatch, InvalidValue); NameDynAnyPairSeq get_members_as_dyn_any() raises(InvalidValue); void set_members_as_dyn_any(in NameDynAnyPairSeq value) raises(TypeMismatch, InvalidValue); }; interface DynValueBox : DynValueCommon { any get_boxed_value() raises(InvalidValue); void set_boxed_value(in any boxed) raises(TypeMismatch); DynAny get_boxed_value_as_dyn_any() raises(InvalidValue); void set_boxed_value_as_dyn_any(in DynAny boxed) raises(TypeMismatch); }; ------------------------------------------------------------------------------ 2. Change the complex type initialization bullet in section 9.2.2 for DynValue from: o For DynValue, the members are initialized as for DynStruct. to: o For DynValue and DynValueBox, initialize to a null value ------------------------------------------------------------------------------ 3. Replace section 9.2.10 with: 9.2.10 The DynValueCommon interface DynValueCommon provides operations supported by both the DynValue and DynValueBox interfaces. [Insert appropriate IDL from above here.] boolean is_null(); The is_null operation returns TRUE if the DynValueCommon represents a null valuetype. void set_to_null(); The set_to_null() operation changes the representation of a DynValueCommon to a null valuetype. void set_to_value(); If the DynValueCommon represents a null valuetype, then set_to_value() replaces it with a newly constructed value, initialized exactly as if DynAnyFactory::create_dyn_any_from_type_code had been invoked. If the DynValueCommon represents a non-null valuetype, then this operation has no effect. 9.2.11 The DynValue interface DynValue objects are associated with non-boxed valuetypes. [Insert appropriate IDL from above here.] The DynValue interface can represent both null and non-null valuetypes. For a DynValue representing a non-null valuetype, the DynValue's components comprise the public and private members of the valuetype, including those inherited from concrete base valuetypes, in the order of definition. A DynValue representing a null valuetype has no components and a current position of -1. The remaining operations on the DynValue interface generally have equivalent semantics to the same operations on DynStruct. When invoked on a DynValue representing a null valuetype, get_members and get_members_as_dyn_any raise InvalidValue. When invoked on a DynValue representing a null valuetype, set_members and set_members_as_dyn_any convert the DynValue to a non-null valuetype. 9.2.12 The DynValueBox interface DynValueBox objects are associated with boxed valuetypes. [Insert appropriate IDL from above here.] The DynValueBox interface can represent both null and non-null valuetypes. For a DynValueBox representing a non-null valuetype, the DynValueBox has a single component of the boxed type. A DynValueBox representing a null valuetype has no components and a current position of -1. any get_boxed_value() raises(InvalidValue); The get_boxed_value operation returns the boxed value as an any. If the DynBoxedValue represents a null valuetype, the operation raises InvalidValue. void set_boxed_value(in any boxed) raises(TypeMismatch); The set_boxed_value replaces the boxed value with the specified value. If the DynBoxedValue represents a null valuetype, it is converted to a non-null value. The get_boxed_value_as_dyn_any and set_boxed_value_as_dyn_any have the same semantics as their any counterparts, but accept and return values of type DynAny instead of any. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 07 Apr 2000 17:25:27 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <38E53CFA.D3AE4EF9@floorboard.com> <38E85284.A5DF4BAB@hursley.ibm.com> <38EE4371.679B2DC7@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: A99e9dl"e9)[Ke9:Dn!! Jon, Jonathan Biggar wrote: > > Simon Nash wrote: > > > > Jon, > > > > Jonathan Biggar wrote: > > > > > > Issue 3135: valuebox and DynAny > > > Issue 3250: Null valuetypes not supported by DynValue > > > > > > [Mark S and I have a disagreement over how DynValue and > DynValueBox > > > should be initialized via the DynAnyFactory operations. He > believes > > > that they should be initialized to a null value, since it is > more > > > consistent and better performing. I agree with the sentiment, > but I > > > think it is better to initialize top level DynValue & > DynValueBox to > > > non-null values, but initialize members of these types as null > values in > > > order to avoid breaking code. > > > > > In the original specification of DynValue, it was stated that > these could > > only be created from an existing valuetype, not created from > scratch. This > > was to ensure that no valuetype could be created whose state > failed to > > satisfy the type invariant for the valuetype implementation. For > the same > > reason, it was stated that the DynValue operations could only be > used to > > access the state of public data members. > > When Michi reworked DynAny, we discussed these rules for valuetypes > and > decided that they weren't workable. If you can't access private > state > members from DynValue, then it is impossible to construct a > consistent > valuetype that has private state members. I find this restriction > would > be much worse than the hole that is opened up to allow access to the > private members. > I must have missed that side-effect of the DynAny changes. There's no problem with constructing a DynValue from an any containing an > existing (valid) valuetype, since the result will be consistent with the type's implementation. But allowing these to be constructed from scratch > opens the door to all kinds of nasty security issues. It means that a > valuetype implementation can receive a valuetype with its private state set to invalid values that could cause the implementation to malfunction in very nasty ways. This will force all valuetype implementers to write code that defends against this possibility (adding considerable effort and complexity) or face dire consequences. It also effectively > negates the ability to have private data in valuetypes since any private data can be extracted by converting the valuetype to a DynValue. I think > we should reconsider this change. > > This came up again later in RTF discussions, and these rules were confirmed. > > And then replaced by later discussion when Michi reworked DynAny. > > > I don't think it is valid to change the inheritance hierarchy of an existing > > type, because of versioning compatibility issues. This introduces a new base > > interface DynValueCommon for DynValue. To do this, I think it would be > > necessary to deprecate the old DynValue class and create a replacement that > > has this base interface. > > Care to explain the perceived problem in more detail? The change > effectively only adds new operations to the class. > I thought we had established a principle that types should be immutable once specified, and extensions need to be done by subtyping. 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: Fri, 07 Apr 2000 17:48:21 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: Second revision of proposal for issues 3135 and 3250 References: <38EE44A3.B76B01D1@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: VjQ!!6i%e9K2c!!=(`!! Jon, Jonathan Biggar wrote: > > Issue 3135: valuebox and DynAny > Issue 3250: Null valuetypes not supported by DynValue > <...cut...> > > void set_to_value(); > > If the DynValueCommon represents a null valuetype, then > set_to_value() > replaces it with a newly constructed value, initialized exactly as > if > DynAnyFactory::create_dyn_any_from_type_code had been invoked. If > the > DynValueCommon represents a non-null valuetype, then this operation > has > no effect. > With the change to null initialization semantics, I believe DynAnyFactory::create_dyn_any_from_type_code sets a DynValue to null. So the above paragraph is almost certainly not saying what was > intended. I think that set_to_value() should be replaced by set_to_value(value) or else removed completely. 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: Fri, 07 Apr 2000 18:00:30 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <38E53CFA.D3AE4EF9@floorboard.com> <38E85284.A5DF4BAB@hursley.ibm.com> <38EE4371.679B2DC7@floorboard.com> <38EE0BF7.6B3DDE5D@hursley.ibm.com> <38EE6611.55B68E95@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: D>j!!/Q~!!TX'e9Kg`d9 Jon, Jonathan Biggar wrote: > > Simon Nash wrote: > > > When Michi reworked DynAny, we discussed these rules for > valuetypes and > > > decided that they weren't workable. If you can't access private > state > > > members from DynValue, then it is impossible to construct a > consistent > > > valuetype that has private state members. I find this > restriction would > > > be much worse than the hole that is opened up to allow access to > the > > > private members. > > > > > I must have missed that side-effect of the DynAny changes. > There's no > > problem with constructing a DynValue from an any containing an > existing > > (valid) valuetype, since the result will be consistent with the > type's > > implementation. But allowing these to be constructed from scratch > opens > > the door to all kinds of nasty security issues. It means that a > valuetype > > implementation can receive a valuetype with its private state set > to > > invalid values that could cause the implementation to malfunction > in > > very nasty ways. This will force all valuetype implementers to > write > > code that defends against this possibility (adding considerable > effort > > and complexity) or face dire consequences. It also effectively > negates > > the ability to have private data in valuetypes since any private > data > > can be extracted by converting the valuetype to a DynValue. I > think we > > should reconsider this change. > > I wouldn't label this a security issue, since no current language > has > any feature that prevents a programmer from messing with private > members > if they really try hard enough. I'd agree to call it an integrity > issue, though. > I think private is truly private in Java except to code that has > special security privileges. > There were several arguments in favor of making private members visible > through DynValue: > > 1. Writing a logging or debugging facility using DynValue that couldn't > get the private members seemed less than useful. > I'm not so bothered by read access. It's write access that's the killer. > 2. Without access to private members, applications which know the > semantics (or can be provided the semantics by a real human) but > don't > have the appropriate code linked in can't construct valuetypes on > the > fly. This would apply to an IFR-driven interface browser that can > invoke operations. > If the semantics/constraints are known, then code can be written or generated that encapsulates these semantics/constraints. And this > code is effectively an implementation of the valuetype. > 3. Many people write scripting language bindings for CORBA by > implementing on top of another language binding, like C++. Without > access to the private members, this is difficult, if not impossible > to > do in a dynamic way. > But you just said above that all languages allow this, so presumably there is some trick that the C++ folks could play even if the API did not allow it :-) > > I thought we had established a principle that types should be immutable > > once specified, and extensions need to be done by subtyping. > > Ok, I've heard the objection. Isn't there some difference for > interfaces that are local? > > If I'm shouted down, I'll probably just take out the inheritence and > copy the operations onto both DynValue & DynValueBox. If you still want > a derived version of DynValue, how about proposing a good name for it. > :-) > Shouldn't it be DynValue_2_4 (assuming this will be in CORBA 2.4)? 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: <38EE6611.55B68E95@floorboard.com> Date: Fri, 07 Apr 2000 15:49:53 -0700 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: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <38E53CFA.D3AE4EF9@floorboard.com> <38E85284.A5DF4BAB@hursley.ibm.com> <38EE4371.679B2DC7@floorboard.com> <38EE0BF7.6B3DDE5D@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6@od99&X!!]lM!!oCHe9 Simon Nash wrote: > > When Michi reworked DynAny, we discussed these rules for > valuetypes and > > decided that they weren't workable. If you can't access private > state > > members from DynValue, then it is impossible to construct a > consistent > > valuetype that has private state members. I find this restriction > would > > be much worse than the hole that is opened up to allow access to > the > > private members. > > > I must have missed that side-effect of the DynAny changes. There's > no > problem with constructing a DynValue from an any containing an > existing > (valid) valuetype, since the result will be consistent with the > type's > implementation. But allowing these to be constructed from scratch > opens > the door to all kinds of nasty security issues. It means that a > valuetype > implementation can receive a valuetype with its private state set to > invalid values that could cause the implementation to malfunction in > very nasty ways. This will force all valuetype implementers to > write > code that defends against this possibility (adding considerable > effort > and complexity) or face dire consequences. It also effectively > negates > the ability to have private data in valuetypes since any private > data > can be extracted by converting the valuetype to a DynValue. I think > we > should reconsider this change. I wouldn't label this a security issue, since no current language has any feature that prevents a programmer from messing with private members if they really try hard enough. I'd agree to call it an integrity issue, though. There were several arguments in favor of making private members visible through DynValue: 1. Writing a logging or debugging facility using DynValue that couldn't get the private members seemed less than useful. 2. Without access to private members, applications which know the semantics (or can be provided the semantics by a real human) but don't have the appropriate code linked in can't construct valuetypes on the fly. This would apply to an IFR-driven interface browser that can invoke operations. 3. Many people write scripting language bindings for CORBA by implementing on top of another language binding, like C++. Without access to the private members, this is difficult, if not impossible to do in a dynamic way. > I thought we had established a principle that types should be immutable > once specified, and extensions need to be done by subtyping. Ok, I've heard the objection. Isn't there some difference for interfaces that are local? If I'm shouted down, I'll probably just take out the inheritence and copy the operations onto both DynValue & DynValueBox. If you still want a derived version of DynValue, how about proposing a good name for it. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@corvette.floorboard.com Message-ID: <38EE69E7.3EEDEE36@floorboard.com> Date: Fri, 07 Apr 2000 16:06:15 -0700 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: orb_revision@omg.org Subject: Re: Second revision of proposal for issues 3135 and 3250 References: <38EE44A3.B76B01D1@floorboard.com> <38EE1155.DD518D0F@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: l&ed99U@!!,0+e9lLL!! Simon Nash wrote: > With the change to null initialization semantics, I believe > DynAnyFactory::create_dyn_any_from_type_code sets a DynValue to > null. > So the above paragraph is almost certainly not saying what was > intended. Yes, you are right. I missed that one in my latest editing round. > I think that set_to_value() should be replaced by set_to_value(value) > or else removed completely. See my other response. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@corvette.floorboard.com Message-ID: <38EE6ADA.475E4064@floorboard.com> Date: Fri, 07 Apr 2000 16:10:18 -0700 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: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <38E53CFA.D3AE4EF9@floorboard.com> <38E85284.A5DF4BAB@hursley.ibm.com> <38EE4371.679B2DC7@floorboard.com> <38EE0BF7.6B3DDE5D@hursley.ibm.com> <38EE6611.55B68E95@floorboard.com> <38EE142E.8632F832@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !0(e9p+(!!k8Ke9p9`!! Simon Nash wrote: > > I wouldn't label this a security issue, since no current language > has > > any feature that prevents a programmer from messing with private > members > > if they really try hard enough. I'd agree to call it an integrity > > issue, though. > > > I think private is truly private in Java except to code that has > special > security privileges. Assuming noone has found a new backdoor. :-) > > 2. Without access to private members, applications which know the > > semantics (or can be provided the semantics by a real human) but > don't > > have the appropriate code linked in can't construct valuetypes on > the > > fly. This would apply to an IFR-driven interface browser that can > > invoke operations. > > > If the semantics/constraints are known, then code can be written or > generated that encapsulates these semantics/constraints. And this > code > is effectively an implementation of the valuetype. But they couldn't implement that valuetype using DynValue. > > 3. Many people write scripting language bindings for CORBA by > > implementing on top of another language binding, like C++. > Without > > access to the private members, this is difficult, if not > impossible to > > do in a dynamic way. > > > But you just said above that all languages allow this, so presumably > there is some trick that the C++ folks could play even if the API > did > not allow it :-) Only in generally non-portable ways, since you have to either grub around in raw memory or else you have to do some nasty type-punning. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sat, 8 Apr 2000 09:20:20 +1000 (EST) From: Michi Henning To: Simon Nash cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38EE0BF7.6B3DDE5D@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: R%cd9Yb$!!Zg!e9,Nid9 On Fri, 7 Apr 2000, Simon Nash wrote: > > > In the original specification of DynValue, it was stated that these could > > > only be created from an existing valuetype, not created from scratch. This > > > was to ensure that no valuetype could be created whose state failed to > > > satisfy the type invariant for the valuetype implementation. For the same > > > reason, it was stated that the DynValue operations could only be used to > > > access the state of public data members. > > > > When Michi reworked DynAny, we discussed these rules for valuetypes and > > decided that they weren't workable. If you can't access private state > > members from DynValue, then it is impossible to construct a consistent > > valuetype that has private state members. I find this restriction would > > be much worse than the hole that is opened up to allow access to the > > private members. Well, some historical info: I asked for volunteers to help with the DynValue part because I didn't feel I knew enough to get it right. No-one came forward, so I only made minimal changes to the DynValue part. After extended discussions among Jishnu, Steve++, Jon Biggar, and myself, we decided to permit construction of values with private state because the original reasoning in the previous DynAny spec was flawed. Basically, it said that private members could not be set because of the inability to maintain invariants. However, that's a red herring. Many values have invariants that extend over both the private and public state members, so allowing construction of only the public members doesn't solve anything. The alternative was to prohibit construction of dynamic values if they have any private members at all, but that would have made DynValue pretty much useless. > I must have missed that side-effect of the DynAny changes. There's no > problem with constructing a DynValue from an any containing an existing > (valid) valuetype, since the result will be consistent with the type's > implementation. But allowing these to be constructed from scratch opens > the door to all kinds of nasty security issues. It means that a valuetype > implementation can receive a valuetype with its private state set to > invalid values that could cause the implementation to malfunction in > very nasty ways. I don't see how a security issue comes into the picture at all. Basically, as a client, I'm being handed a value with private data. That value is passed into my address space and there is nothing to prevent me from changing it if I try hard enough. (For example, in C++, I can just take a pointer to the private part of the value and hack the memory any way I see fit.) > This will force all valuetype implementers to write > code that defends against this possibility (adding considerable > effort > and complexity) or face dire consequences. It also effectively > negates > the ability to have private data in valuetypes since any private > data > can be extracted by converting the valuetype to a DynValue. I think > we > should reconsider this change. There is no such thing a "private" data once a value has entered an address space. Any notion of privacy is purely illusory and maintained only by scoping or access conventions in the target language. Basically, if you want to permit dynamic construction of values at all, you must permit construction of the private parts. It's inevitable. The only alternative is to not permit construction of values with private members at all. Permitting construction of the public members only is useless because it implicitly assumes that default-constructed private members will never violate their invariants, which is a naive assumption. > > > This came up again later in RTF discussions, and these rules were confirmed. > > > > And then replaced by later discussion when Michi reworked DynAny. > > > > > I don't think it is valid to change the inheritance hierarchy of an existing > > > type, because of versioning compatibility issues. This introduces a new base > > > interface DynValueCommon for DynValue. To do this, I think it would be > > > necessary to deprecate the old DynValue class and create a replacement that > > > has this base interface. > > > > Care to explain the perceived problem in more detail? The change > > effectively only adds new operations to the class. > > > I thought we had established a principle that types should be immutable > once specified, and extensions need to be done by subtyping. For things are local only, you get a way with a lot more because any inconsistencies will show up at compile time. (Otherwise, we could never modify other parts of the core either, such as the ORB, Object, or any number of other things.) 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 Date: Sat, 8 Apr 2000 09:22:16 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Simon Nash , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38EE6611.55B68E95@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 1;Ld9Wned9e83!!G0X!! On Fri, 7 Apr 2000, Jonathan Biggar wrote: > > I thought we had established a principle that types should be immutable > > once specified, and extensions need to be done by subtyping. > > Ok, I've heard the objection. Isn't there some difference for > interfaces that are local? > > If I'm shouted down, I'll probably just take out the inheritence and > copy the operations onto both DynValue & DynValueBox. If you still want > a derived version of DynValue, how about proposing a good name for it. > :-) I don't think that a derived type will be necessary because the interface is local anyway. 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 Date: Sat, 8 Apr 2000 09:36:06 +1000 (EST) From: Michi Henning To: Simon Nash cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38EE142E.8632F832@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: RCOe9Mj5e97]0!!P/)!! On Fri, 7 Apr 2000, Simon Nash wrote: > > 2. Without access to private members, applications which know the > > semantics (or can be provided the semantics by a real human) but > don't > > have the appropriate code linked in can't construct valuetypes on > the > > fly. This would apply to an IFR-driven interface browser that can > > invoke operations. > > > If the semantics/constraints are known, then code can be written or > generated that encapsulates these semantics/constraints. And this > code > is effectively an implementation of the valuetype. Huh? I don't understand. I want to construct a valuetype with private members from scratch. I don't have any type information available other than what I get from the IFR. How can I construct a value if I don't have static information about the value and therefore no code for its implementation if not by explicitly setting the private members? Basically, the reality is that private data and dynamic construction don't go together very well. That's just how it is. Disallowing write access to private data via DynValue doesn't solve that inherent problem. However, allowing access to that data does solve at least some problems. > > 3. Many people write scripting language bindings for CORBA by > > implementing on top of another language binding, like C++. > Without > > access to the private members, this is difficult, if not > impossible to > > do in a dynamic way. > > > But you just said above that all languages allow this, so presumably > > there is some trick that the C++ folks could play even if the API > did > not allow it :-) See my previous posting. The only way to get real privacy would be to either keep the private data in a separate address space, or to keep the private data at a separate hardware protection level. Both options are unrealistic because they assume that somewhere, there is code that knows how to deal with the private data in order to maintain its invariants. However, the whole point of dynamic construction is that there *is* no such code (otherwise, I wouldn't need dynamic construction in the first place). > Shouldn't it be DynValue_2_4 (assuming this will be in CORBA 2.4)? I don't think that's necessary. New code that uses the extra functions won't compile if compiled with the previous DynAny, so I find out at compile time that I have an ORB that doesn't support the 2.4 version. Old code that uses the new version won't see any difference, so its backward compatible. That's good enough, as far as I can see. 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 Date: Sat, 8 Apr 2000 09:37:40 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Simon Nash , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38EE6ADA.475E4064@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: [cR!!j7f!![:Ud92_'e9 On Fri, 7 Apr 2000, Jonathan Biggar wrote: > > But you just said above that all languages allow this, so presumably > > there is some trick that the C++ folks could play even if the API did > > not allow it :-) > > Only in generally non-portable ways, since you have to either grub > around in raw memory or else you have to do some nasty type-punning. Sure, but there still is no real privacy. The only way to get that would be to have separate protection levels in the CPU, but current-generation CPUs don't support that. 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 X-Sender: mark@192.168.1.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 07 Apr 2000 16:40:54 -0700 To: Simon Nash , Jonathan Biggar From: Mark Spruiell Subject: Re: Second revision of proposal for issues 3135 and 3250 Cc: orb_revision@omg.org In-Reply-To: <38EE1155.DD518D0F@hursley.ibm.com> References: <38EE44A3.B76B01D1@floorboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: [^~e98o>e9 If the DynValueCommon represents a null valuetype, then > set_to_value() > replaces it with a newly constructed value, initialized exactly as > if > DynAnyFactory::create_dyn_any_from_type_code had been invoked. If > the > DynValueCommon represents a non-null valuetype, then this operation > has > no effect. > With the change to null initialization semantics, I believe DynAnyFactory::create_dyn_any_from_type_code sets a DynValue to null. So the above paragraph is almost certainly not saying what was > intended. Right. I think that set_to_value() should be replaced by set_to_value(value) or else removed completely. Your assumption that a client using DynValue will have an instance of a valuetype seems to contradict the common use cases. If a client has a valuetype instance, the client can simply insert it into the Any using the mechanism provided by the language mapping, and has no need for DynValue. I tend to think of DynValue as being most useful in environments where there are no factories/helpers available, therefore no possibility for the ORB to instantiate valuetypes. In this environment, the Any will contain the marshalled representation of the valuetype. One example is a notification service, which cannot be expected to have factories for every possible valuetype that is pushed through the service, yet may need to perform filtering on the members of a valuetype. Similarly, DII-based clients need a way to create valuetype parameters. These clients don't need valuetype instances, they just need the Any to contain the marshalled form of the valuetype. If clients are not allowed to modify the private members, this cannot possibly work. Finally, if set_to_value() is removed, then the only way to construct a DynValue is by first calling set_members/set_members_as_dyn_any. The intent of set_to_value() was to intitialize the valuetype members so that the components could be traversed individually, as with other constructed types. Take care, Mark -- Mark E. Spruiell Object Oriented Concepts, Inc. mes@ooc.com * http://www.ooc.com * 1-978-439-9285 x 247 From: Paul Kyzivat To: orb_revision@omg.org Subject: RE: Revised proposal for issues 3135 and 3250 Date: Fri, 7 Apr 2000 20:51:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 4bG!!gC-!!\'+!!ZeTd9 > From: Simon Nash [mailto:nash@hursley.ibm.com] > > I wouldn't label this a security issue, since no current > language has > > any feature that prevents a programmer from messing with > private members > > if they really try hard enough. I'd agree to call it an integrity > > issue, though. > > > I think private is truly private in Java except to code that > has special security privileges. You can only maintain consistent state when the valuetypes methods are always used to access the state. Java seems to be the only language that has even half a claim to being able to prevent direct access from a determined user. And there are limits even there. In java, can't I use serialization to convert my valuetype to a string? Then I can modify the part of the string that contains the private data members, and invert the serialization to restore the valuetype with the revised value. This is without IIOP or CORBA in the picture at all. To protect against this, I would expect that the serialization code must cooperate with the valuetype's methods to ensure that the values reconstructed are valid. Presumably the same technique would be used with RMI/IIOP to protect against bad bits arriving over the wire. DynValue doesn't seem substantially different. Constructing an any from a DynAny containing a DynValue should do all the same stuff, including possibly throwing a MARSHAL exception, or something to that effect. Paul Date: Mon, 10 Apr 2000 22:19:33 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: > On Fri, 7 Apr 2000, Simon Nash wrote: > > > > > In the original specification of DynValue, it was stated that > these could > > > > only be created from an existing valuetype, not created from > scratch. This > > > > was to ensure that no valuetype could be created whose state > failed to > > > > satisfy the type invariant for the valuetype implementation. > For the same > > > > reason, it was stated that the DynValue operations could only > be used to > > > > access the state of public data members. > > > > > > When Michi reworked DynAny, we discussed these rules for > valuetypes and > > > decided that they weren't workable. If you can't access private > state > > > members from DynValue, then it is impossible to construct a > consistent > > > valuetype that has private state members. I find this > restriction would > > > be much worse than the hole that is opened up to allow access to > the > > > private members. > > Well, some historical info: I asked for volunteers to help with the > DynValue > part because I didn't feel I knew enough to get it right. No-one > came forward, > so I only made minimal changes to the DynValue part. After extended > discussions > among Jishnu, Steve++, Jon Biggar, and myself, we decided to permit > construction of values with private state because the original > reasoning > in the previous DynAny spec was flawed. Basically, it said that > private > members could not be set because of the inability to maintain > invariants. > However, that's a red herring. Many values have invariants that > extend over > both the private and public state members, so allowing construction > of > only the public members doesn't solve anything. The alternative was > to prohibit construction of dynamic values if they have any private > members > at all, but that would have made DynValue pretty much useless. > There is no invariant issue with allowing public members to be set to > arbitrary values. Since public members are modifyable at any time by anyone who > has access to the valuetype object, no invariants can ever be assumed > about the state of public variables. > > I must have missed that side-effect of the DynAny changes. There's no > > problem with constructing a DynValue from an any containing an existing > > (valid) valuetype, since the result will be consistent with the type's > > implementation. But allowing these to be constructed from scratch opens > > the door to all kinds of nasty security issues. It means that a valuetype > > implementation can receive a valuetype with its private state set to > > invalid values that could cause the implementation to malfunction in > > very nasty ways. > > I don't see how a security issue comes into the picture at all. Basically, > as a client, I'm being handed a value with private data. That value is > passed into my address space and there is nothing to prevent me from changing > it if I try hard enough. (For example, in C++, I can just take a pointer to > the private part of the value and hack the memory any way I see fit.) > My sympathy goes out to C++ programmers who have to be concerned about such things. They aren't possible in Java. What you are saying is that this change only causes problems for Java, not for C++. That doesn't make me feel any better about it. > > This will force all valuetype implementers to write > > code that defends against this possibility (adding considerable > effort > > and complexity) or face dire consequences. It also effectively > negates > > the ability to have private data in valuetypes since any private > data > > can be extracted by converting the valuetype to a DynValue. I > think we > > should reconsider this change. > > There is no such thing a "private" data once a value has entered an > address > space. Any notion of privacy is purely illusory and maintained only > by > scoping or access conventions in the target language. > It is possible (at least in theory) to have a language which strictly enforces this privacy. CORBA should not subvert the integrity of such languages by adding flaky trapdoors. > Basically, if you want to permit dynamic construction of values at all, > you must permit construction of the private parts. It's inevitable. The only > alternative is to not permit construction of values with private members > at all. Permitting construction of the public members only is useless because > it implicitly assumes that default-constructed private members will never > violate their invariants, which is a naive assumption. > I agree. This is why I don't think it should be possible to construct a DynValue from scratch, only from an existing well-formed valuetype instance. Simon > > > > This came up again later in RTF discussions, and these rules were confirmed. > > > > > > And then replaced by later discussion when Michi reworked DynAny. > > > > > > > I don't think it is valid to change the inheritance hierarchy of an existing > > > > type, because of versioning compatibility issues. This introduces a new base > > > > interface DynValueCommon for DynValue. To do this, I think it would be > > > > necessary to deprecate the old DynValue class and create a replacement that > > > > has this base interface. > > > > > > Care to explain the perceived problem in more detail? The change > > > effectively only adds new operations to the class. > > > > > I thought we had established a principle that types should be immutable > > once specified, and extensions need to be done by subtyping. > > For things are local only, you get a way with a lot more because any > inconsistencies will show up at compile time. (Otherwise, we could never > modify other parts of the core either, such as the ORB, Object, or any > number of other things.) > > 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 -- 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, 10 Apr 2000 22:28:34 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +eQd98/I!!5PD!!aeR!! Michi, Michi Henning wrote: > > On Fri, 7 Apr 2000, Simon Nash wrote: > > > > 2. Without access to private members, applications which know > the > > > semantics (or can be provided the semantics by a real human) but > don't > > > have the appropriate code linked in can't construct valuetypes > on the > > > fly. This would apply to an IFR-driven interface browser that > can > > > invoke operations. > > > > > If the semantics/constraints are known, then code can be written > or > > generated that encapsulates these semantics/constraints. And this > code > > is effectively an implementation of the valuetype. > > Huh? I don't understand. I want to construct a valuetype with > private > members from scratch. I don't have any type information available > other > than what I get from the IFR. How can I construct a value if I don't > have static information about the value and therefore no code for > its > implementation if not by explicitly setting the private members? > If you really have no other information about the behavior of the type > and its invariants, then it is extremely dangerous to construct it and set > its private data. > Basically, the reality is that private data and dynamic construction don't > go together very well. That's just how it is. Disallowing write access to > private data via DynValue doesn't solve that inherent problem. However, > allowing access to that data does solve at least some problems. > > > > 3. Many people write scripting language bindings for CORBA by > > > implementing on top of another language binding, like C++. Without > > > access to the private members, this is difficult, if not impossible to > > > do in a dynamic way. > > > > > But you just said above that all languages allow this, so presumably > > there is some trick that the C++ folks could play even if the API did > > not allow it :-) > > See my previous posting. The only way to get real privacy would be to > either keep the private data in a separate address space, or to keep > the private data at a separate hardware protection level. Both options > are unrealistic because they assume that somewhere, there is code that > knows how to deal with the private data in order to maintain its invariants. > However, the whole point of dynamic construction is that there *is* no > such code (otherwise, I wouldn't need dynamic construction in the first place). > The code exists somewhere. Only in such places is it safe to allow the private state of the valuetype be manipulated. I am saying that in the absence of such code, it is unsafe to construct a valuetype with private members. You assert that such a limitation is intolerable. I assert that the security/integrity hole created by allowing this is intolerable. I doubt that we will come to a meeting of minds on this. > > Shouldn't it be DynValue_2_4 (assuming this will be in CORBA 2.4)? > > I don't think that's necessary. New code that uses the extra > functions won't > compile if compiled with the previous DynAny, so I find out at > compile time > that I have an ORB that doesn't support the 2.4 version. Old code > that > uses the new version won't see any difference, so its backward > compatible. > That's good enough, as far as I can see. > Old code that isn't recompiled could have problems if a type it is > using gains a new superclass, at least in some languages, couldn't it? 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, 10 Apr 2000 22:30:00 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: El7!!I(C!!HD`d9F4+!! Michi, Michi Henning wrote: > > On Fri, 7 Apr 2000, Jonathan Biggar wrote: > > > > But you just said above that all languages allow this, so > presumably > > > there is some trick that the C++ folks could play even if the > API did > > > not allow it :-) > > > > Only in generally non-portable ways, since you have to either grub > > around in raw memory or else you have to do some nasty > type-punning. > > Sure, but there still is no real privacy. The only way to get that > would > be to have separate protection levels in the CPU, but > current-generation > CPUs don't support that. > Actually, there are some. IBM's S/390 and AS/400, for example. 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, 10 Apr 2000 22:35:10 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Spruiell CC: Jonathan Biggar , orb_revision@omg.org Subject: Re: Second revision of proposal for issues 3135 and 3250 References: <38EE44A3.B76B01D1@floorboard.com> <4.3.1.2.20000407161821.01f15860@192.168.1.1> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: jJ9e9g)"e9k7~!!,F%e9 Mark, Mark Spruiell wrote: > > At 09:48 AM 4/7/00, Simon Nash wrote: > > > If the DynValueCommon represents a null valuetype, then > set_to_value() > > > replaces it with a newly constructed value, initialized exactly > as if > > > DynAnyFactory::create_dyn_any_from_type_code had been invoked. > If the > > > DynValueCommon represents a non-null valuetype, then this > operation has > > > no effect. > > > > >With the change to null initialization semantics, I believe > >DynAnyFactory::create_dyn_any_from_type_code sets a DynValue to > null. > >So the above paragraph is almost certainly not saying what was > intended. > > Right. > > >I think that set_to_value() should be replaced by > set_to_value(value) > >or else removed completely. > > Your assumption that a client using DynValue will have an instance > of a valuetype seems to contradict the common use cases. If a client > has a valuetype instance, the client can simply insert it into the > Any > using the mechanism provided by the language mapping, and has no > need > for DynValue. > > I tend to think of DynValue as being most useful in environments > where > there are no factories/helpers available, therefore no possibility > for > the ORB to instantiate valuetypes. In this environment, the Any will > contain the marshalled representation of the valuetype. One example > is > a notification service, which cannot be expected to have factories > for > every possible valuetype that is pushed through the service, yet may > need > to perform filtering on the members of a valuetype. > That's fine. This doesn't require constructing DynValues from > scratch. > Similarly, DII-based clients need a way to create valuetype parameters. > These clients don't need valuetype instances, they just need the Any > to contain the marshalled form of the valuetype. If clients are > not allowed to modify the private members, this cannot possibly work. > If the valuetype members are public, there is no problem. Declaring members as private is supposed to be a declaration that direct access to them should not be possible, and therefore that this should not be allowed. The effect of this is more or less to remove the public/private distinction. Simon > Finally, if set_to_value() is removed, then the only way to construct > a DynValue is by first calling set_members/set_members_as_dyn_any. > The intent of set_to_value() was to intitialize the valuetype members > so that the components could be traversed individually, as with other > constructed types. > > Take care, > > Mark > -- > Mark E. Spruiell > Object Oriented Concepts, Inc. > mes@ooc.com * http://www.ooc.com * 1-978-439-9285 x 247 -- 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: <38F25172.83322FBB@fpk.hp.com> Date: Mon, 10 Apr 2000 18:10:58 -0400 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: Simon Nash Cc: Michi Henning , Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <38F247D8.DCE2215@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Gk&e97ih!!VF*e9A[a!! Simon Nash wrote: > > Michi, > > Michi Henning wrote: > > > > On Fri, 7 Apr 2000, Jonathan Biggar wrote: > > > > > > But you just said above that all languages allow this, so > presumably > > > > there is some trick that the C++ folks could play even if the > API did > > > > not allow it :-) > > > > > > Only in generally non-portable ways, since you have to either > grub > > > around in raw memory or else you have to do some nasty > type-punning. > > > > Sure, but there still is no real privacy. The only way to get that > would > > be to have separate protection levels in the CPU, but > current-generation > > CPUs don't support that. > > > Actually, there are some. IBM's S/390 and AS/400, for example. Add to that PA-RISC and Merced, if anyone particularly cares. As it turns out the tagged memory access part of the architecture is seldom used in its fullest glory by anyone (so far). Jishnu Date: Tue, 11 Apr 2000 08:11:59 +1000 (EST) From: Michi Henning To: Simon Nash cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38F24565.F5D60C75@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: f0 > I don't see how a security issue comes into the picture at all. Basically, > > as a client, I'm being handed a value with private data. That value is > > passed into my address space and there is nothing to prevent me from changing > > it if I try hard enough. (For example, in C++, I can just take a pointer to > > the private part of the value and hack the memory any way I see fit.) > > > My sympathy goes out to C++ programmers who have to be concerned about such > things. They aren't possible in Java. Simon, your sympathy will have to go out to more than just C++ programmers. The protection issues I mentioned affect many other languages. > > There is no such thing a "private" data once a value has entered an address > > space. Any notion of privacy is purely illusory and maintained only by > > scoping or access conventions in the target language. > > > It is possible (at least in theory) to have a language which strictly > enforces this privacy. CORBA should not subvert the integrity of such > languages by adding flaky trapdoors. CORBA also has to work with languages other than Java. > > Basically, if you want to permit dynamic construction of values at all, > > you must permit construction of the private parts. It's inevitable. The only > > alternative is to not permit construction of values with private members > > at all. Permitting construction of the public members only is useless because > > it implicitly assumes that default-constructed private members will never > > violate their invariants, which is a naive assumption. > > > I agree. This is why I don't think it should be possible to construct > a DynValue from scratch, only from an existing well-formed valuetype > instance. Well, the original spec *did* permit construction of value types, so the changes we made were an attempt at preserving the original intent. Of course, we could make dynamic construction of valuetypes impossible altogether (apart from permitting construction from an existing value type). I'm not sure what the ramifications of such a decision would be though. Would this be an acceptable thing to do? 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: <38F25583.E8707E31@floorboard.com> Date: Mon, 10 Apr 2000 15:28:20 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Simon Nash , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: d`&e94a>e9)VVd9,/$"! Michi Henning wrote: > Well, the original spec *did* permit construction of value types, so > the > changes we made were an attempt at preserving the original > intent. Of course, > we could make dynamic construction of valuetypes impossible > altogether > (apart from permitting construction from an existing value > type). I'm not > sure what the ramifications of such a decision would be > though. Would this > be an acceptable thing to do? I still don't think it is a good idea to prohibit dynamic construction. Are we going to only prohibit it for valuetypes that have private state? Certainly it should be ok to dynamically construct a valuetype that only has public state. It still prohibits the following, or makes them difficult: 1. Scripting language bindings built on top of other ORB language bindings. 2. User driven browsing/invocation construction. 3. Script driven debugging/testing frameworks. Not providing dynamic access to private members, which really only results in security through obscurity for most ORB environments, does not provide benefits worth the cost of loosing the above features. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Paul Kyzivat To: orb_revision@omg.org Subject: RE: Revised proposal for issues 3135 and 3250 Date: Mon, 10 Apr 2000 18:30:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: '[/!!-K!!!d^>e9fD^!! > From: Simon Nash [mailto:nash@hursley.ibm.com] > > Sure, but there still is no real privacy. The only way to > get that would > > be to have separate protection levels in the CPU, but > current-generation > > CPUs don't support that. > > > Actually, there are some. IBM's S/390 and AS/400, for example. Over the years there have been a variety of attempts to introduce capability-based architectures. Honeywell made one, Intel made at least one, I guess IBM has made a couple or more. But as far as I know, nobody has ever done it in a way that turned out to be practical for guaranteeing semantic integrity of fine grained data structures. (I don't know much about the AS/400, but I think it is a descendent of the S/38. Based on the little I have heard about these, they may have been more successful in realizing this goal.) But the popular existing compiled languages (with the exception of Java) could probably not be implemented in a compliant way while enforcing this level of protection. I do however agree with you that in principle languages could offer this degree of protection. I would be happy to see CORBA accomodate that, but as with everything else, there are probably compromises to be made. If this makes other language mappings impractical than it is probably a bad choice. In this case, as I mentioned in another message, it would make sense to permit this with DynValue, and do the needed consistency checking when converting it to a valuetype. Paul Date: Tue, 11 Apr 2000 09:03:45 +1000 (EST) From: Michi Henning To: Simon Nash cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38F247D8.DCE2215@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: o05!!_mM!!]+,!!U3hd9 On Mon, 10 Apr 2000, Simon Nash wrote: > > Sure, but there still is no real privacy. The only way to get that would > > be to have separate protection levels in the CPU, but current-generation > > CPUs don't support that. > > > Actually, there are some. IBM's S/390 and AS/400, for example. They are not current generation CPU's ;-) Michi. Date: Tue, 11 Apr 2000 09:07:33 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Simon Nash , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38F25583.E8707E31@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: "`G!!n4l!!A I still don't think it is a good idea to prohibit dynamic construction. > Are we going to only prohibit it for valuetypes that have private > state? Certainly it should be ok to dynamically construct a valuetype > that only has public state. I agree. The options are basically: - Permit composition of all value types, including ones with private members. - Disallow composition of all value types that have private members. The third alternative, namely, to permit composition of value types with private members, but only allow the public members to be set, is useless, IMO. > It still prohibits the following, or makes them difficult: > > 1. Scripting language bindings built on top of other ORB language > bindings. > 2. User driven browsing/invocation construction. > 3. Script driven debugging/testing frameworks. > > Not providing dynamic access to private members, which really only > results in security through obscurity for most ORB environments, > does > not provide benefits worth the cost of loosing the above features. I agree with you. 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: orb_revision@omg.org Subject: RE: Revised proposal for issues 3135 and 3250 Date: Mon, 10 Apr 2000 19:37:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: CIk!!p)B!!+\)!!GlT!! > Well, the original spec *did* permit construction of value > types, so the > changes we made were an attempt at preserving the original > intent. Of course, > we could make dynamic construction of valuetypes impossible > altogether > (apart from permitting construction from an existing value > type). I'm not > sure what the ramifications of such a decision would be > though. Would this > be an acceptable thing to do? It would eliminate any possibility of a general purpose debugger or exerciser. Paul From: Paul Kyzivat To: orb_revision@omg.org Subject: RE: Revised proposal for issues 3135 and 3250 Date: Mon, 10 Apr 2000 19:53:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: =WNe9d6id9A(o!!mSB!! I send a message on this subject on Friday that hasn't been referenced, so maybe it got lost. (Or maybe everybody thought I was crazy.) In any case I will try again. If a language (like Java) is concerned about enforcing the consistency of the valuetype state, then it needs to protect itself when it receives the state from a source it doesn't control. One such source is an GIOP stream being unmarshalled. You can never know who might have been messing with that data. So, when unmarshalling, you can initialize the private data from the stream, but before completion there should be some means of verifying that the state is valid. This is true whether the stream is via an IIOP connection, or whether it is an encapsulation. (With the PI stuff we have provided a way to encode/decode encapsulations. There is nothing to stop me from encoding a valuetype as an encapsulation, hacking on the bytes in the encapsulation to change private data, and then decoding the encapsulation. It should be possible to do this in Java as soon as there is a PI implementation - perhaps OOC can do it now!) DynValue is essentially the same - converting a DynValue to a valuetype is equivalent in security risk to decoding an encapsulation containing a valuetype. So, I think it is fruitless to draw the rules in an attempt to let Java trust what it decodes from a GIOP stream. Better for the Java RTF to work on how to validate the type after it has been decoded. Paul Date: Tue, 11 Apr 2000 11:55:22 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: T&>e9%8,!!G'=!!c9&!! Michi, Michi Henning wrote: > > On Mon, 10 Apr 2000, Simon Nash wrote: > > > > I don't see how a security issue comes into the picture at > all. Basically, > > > as a client, I'm being handed a value with private data. That > value is > > > passed into my address space and there is nothing to prevent me > from changing > > > it if I try hard enough. (For example, in C++, I can just take a > pointer to > > > the private part of the value and hack the memory any way I see > fit.) > > > > > My sympathy goes out to C++ programmers who have to be concerned > about such > > things. They aren't possible in Java. > > Simon, your sympathy will have to go out to more than just C++ > programmers. > The protection issues I mentioned affect many other languages. > > > > There is no such thing a "private" data once a value has entered > an address > > > space. Any notion of privacy is purely illusory and maintained > only by > > > scoping or access conventions in the target language. > > > > > It is possible (at least in theory) to have a language which > strictly > > enforces this privacy. CORBA should not subvert the integrity of > such > > languages by adding flaky trapdoors. > > CORBA also has to work with languages other than Java. > CORBA specifies language-neutral semantics. These include the > "private" keyword in IDL. Either this has reliable CORBA-defined semantics or it > doesn't. If it truly means "private" only in some languages, then its semantics > are meaningless and we may as well deprecate it (not that I want to do > this). And even if my whole system is Java, opening up this DynValue hole means that any private field in any valuetype may be modified by anyone who feels like doing so. So any security/integrity I thought that Java has buying me has just gone out the window. > > > Basically, if you want to permit dynamic construction of values at all, > > > you must permit construction of the private parts. It's inevitable. The only > > > alternative is to not permit construction of values with private members > > > at all. Permitting construction of the public members only is useless because > > > it implicitly assumes that default-constructed private members will never > > > violate their invariants, which is a naive assumption. > > > > > I agree. This is why I don't think it should be possible to construct > > a DynValue from scratch, only from an existing well-formed valuetype > > instance. > > Well, the original spec *did* permit construction of value types, so the > changes we made were an attempt at preserving the original intent. Of course, > we could make dynamic construction of valuetypes impossible altogether > (apart from permitting construction from an existing value type). I'm not > sure what the ramifications of such a decision would be though. Would this > be an acceptable thing to do? > If you are referring to the original OBV spec, this did not permit construction of valuetypes except via initializers provided by the valuetype implementation. Construction of DynValue from scratch was specifically prohibited in this spec because of the type invariant issue. 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, 11 Apr 2000 13:46:09 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <9B164B713EE9D211B6DC0090273CEEA926BDC0@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: VR$e9Fhld9BG!"!*oi!! Paul, I did see your earlier message but I did not respond yesterday because I was thinking about your arguments. I have a lot of sympathy with most of what you are saying. The part that concerns me is your assertion that the contents of a GIOP stream cannot be trusted. There certainly are mechanisms like SSL that can ensure that the data received is the same as the data sent. And if the sending system's integrity can be trusted, that data should be valid. So I disagree that every Java valuetype unmarshalling operation should need to carry the overhead of performing integrity checking. This presumption of integrity applies to a parameter whose declared type is a valuetype being sent across the wire. If an any containing a valuetype is sent across the wire, then the receiver must explicitly extract the valuetype from the any before calling any valuetype methods, and I agree that this extraction operation provides an opportunity for integrity checking. As you suggest, this could be handled as an issue of whether the Java binding (and other language bindings) should provide a way for running integrity checking code on a valuetype language object after it has been constructed by extraction from an any (or encapsulation). For example, there could be a special method called "validate" which if defined would be called automatically following the extraction. Alternatively we could punt and say that since extraction is a programmatic operation performed explicitly by a programmer, the programmer is responsible for calling an appropriate validation method on the valuetype implementation immediately after extraction. In any case we should document the potential integrity issues with setting private members of a DynValue. Simon Paul Kyzivat wrote: > > I send a message on this subject on Friday that hasn't been > referenced, so > maybe it got lost. (Or maybe everybody thought I was crazy.) In any > case I > will try again. > > If a language (like Java) is concerned about enforcing the > consistency of > the valuetype state, then it needs to protect itself when it > receives the > state from a source it doesn't control. > > One such source is an GIOP stream being unmarshalled. You can never > know who > might have been messing with that data. So, when unmarshalling, you > can > initialize the private data from the stream, but before completion > there > should be some means of verifying that the state is valid. This is > true > whether the stream is via an IIOP connection, or whether it is an > encapsulation. > > (With the PI stuff we have provided a way to encode/decode > encapsulations. > There is nothing to stop me from encoding a valuetype as an > encapsulation, > hacking on the bytes in the encapsulation to change private data, > and then > decoding the encapsulation. It should be possible to do this in Java > as soon > as there is a PI implementation - perhaps OOC can do it now!) > > DynValue is essentially the same - converting a DynValue to a > valuetype is > equivalent in security risk to decoding an encapsulation containing > a > valuetype. > > So, I think it is fruitless to draw the rules in an attempt to let > Java > trust what it decodes from a GIOP stream. Better for the Java RTF to > work on > how to validate the type after it has been decoded. > > Paul -- 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 Subject: RE: Revised proposal for issues 3135 and 3250 Date: Tue, 11 Apr 2000 10:51:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: $edd9AY2e9BF%e9QPP!! > From: Simon Nash [mailto:nash@hursley.ibm.com] > I have a lot of sympathy with most of what you are saying. > The part that > concerns me is your assertion that the contents of a GIOP > stream cannot be > trusted. There certainly are mechanisms like SSL that can ensure > that > the data received is the same as the data sent. And if the > sending system's > integrity can be trusted, that data should be valid. So I > disagree that > every Java valuetype unmarshalling operation should need to carry > the > overhead of performing integrity checking. I agree that in some cases it may be acceptable to trust the source of the data. But it is pretty difficult to take advantage of that in the code, because the decision about when the source can be trusted and when it cannot are probably dynamic rather than static. So, the code at least needs a means to protect itself, unless there is a general policy to be trusting. Even in the case of an SSL connection, there is plenty of opportunity for error. If there are distinct implementations of the valuetype at the two ends of the conversation, one of them may be incorrect (intentionally or accidentally). Should the other implementation depend on that correctness for its own correct functioning? As a simpler example - in our orb we always verify, on the receiving side, that enum values are in range. Paul Date: Tue, 11 Apr 2000 16:41:43 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <9B164B713EE9D211B6DC0090273CEEA926BDC3@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 9R/e9Ym!e9V:De9n+nd9 Paul, Paul Kyzivat wrote: > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > I have a lot of sympathy with most of what you are saying. > > The part that > > concerns me is your assertion that the contents of a GIOP > > stream cannot be > > trusted. There certainly are mechanisms like SSL that can ensure > that > > the data received is the same as the data sent. And if the > > sending system's > > integrity can be trusted, that data should be valid. So I > > disagree that > > every Java valuetype unmarshalling operation should need to carry > the > > overhead of performing integrity checking. > > I agree that in some cases it may be acceptable to trust the source > of the > data. But it is pretty difficult to take advantage of that in the > code, > because the decision about when the source can be trusted and when > it cannot > are probably dynamic rather than static. > > So, the code at least needs a means to protect itself, unless there > is a > general policy to be trusting. > In a totally insecure system, no check is needed. Likewise in a > totally secure system. For mixtures, the means to check is needed. > Even in the case of an SSL connection, there is plenty of opportunity for > error. If there are distinct implementations of the valuetype at the two > ends of the conversation, one of them may be incorrect (intentionally or > accidentally). Should the other implementation depend on that correctness > for its own correct functioning? > SSL implies that the receiver knows the sender's identity. So it should be possible to only accept connections from senders that are known to be trusted and internally secure (no bogus implementations can exist on them). In this case an integrity check could be optimized out. > As a simpler example - in our orb we always verify, on the receiving side, > that enum values are in range. > That's cheap and easy to do, since this invariant is declared in IDL. However, the equivalent for valuetypes would require a "validate" method provided by the valuetype implementer. An alternative would be to make all valuetypes custom unmarshaled, and perform the integrity check within the custom unmarshaling method. In the case of RMI-IIOP, this would require writing a readObject method with a call to defaultReadObject followed by the validation check. 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 From: Paul Kyzivat To: orb_revision@omg.org Subject: RE: Revised proposal for issues 3135 and 3250 Date: Tue, 11 Apr 2000 12:30:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: +/h!! From: Simon Nash [mailto:nash@hursley.ibm.com] > In a totally insecure system, no check is needed. Likewise > in a totally > secure system. For mixtures, the means to check is needed. > SSL implies that the receiver knows the sender's identity. > So it should be > possible to only accept connections from senders that are > known to be trusted > and internally secure (no bogus implementations can exist on > them). In this > case an integrity check could be optimized out. So, how do you propose to take advantage of this? Will your code only support totally secure and totally insecure environments? Won't your customers expect you to support environments that are not totally secure? An example of an environment that is not totally secure is one that uses DynValue to create a new valuetype, including the private state. Just because it isn't totally secure doesn't mean it should be banned. It is a useful thing to have, especially during debugging. Another example of an environment that is not totally secure is one that includes code in c++. At least the runtime cannot *guarantee* that a valuetype is fully consistent. (Perhaps an audit of all the code can guarantee that, to some degree.) Paul Sender: jis@fpk.hp.com Message-ID: <38F362B4.C316B421@fpk.hp.com> Date: Tue, 11 Apr 2000 13:36:52 -0400 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: Simon Nash Cc: Paul Kyzivat , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <9B164B713EE9D211B6DC0090273CEEA926BDC3@bos1.noblenet.com> <38F347B7.6AD3B270@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 'L%"!&(@e9?WU!!64+!! Simon Nash wrote: > > Paul, > > Paul Kyzivat wrote: > > > Even in the case of an SSL connection, there is plenty of > opportunity for > > error. If there are distinct implementations of the valuetype at > the two > > ends of the conversation, one of them may be incorrect > (intentionally or > > accidentally). Should the other implementation depend on that > correctness > > for its own correct functioning? > > > SSL implies that the receiver knows the sender's identity. So it > should be > possible to only accept connections from senders that are known to > be trusted > and internally secure (no bogus implementations can exist on them). > In this > case an integrity check could be optimized out. One minor nit. SSL by itself does not imply anything like what is claimed above. An SSL connection setup with appropriate options (Client Auth) does imply what is claimed. So, yes, if a client autheticated SSL connection is setup, and one chooses to trust the authenticated client, and the entire setup that said client is executing in, then the rest might follow. Of course the leap from "knowing the sender's identity" to the "correctness of all the code that s/he is executing" could be a phenomenal one.:-) Jishnu. Sender: jis@fpk.hp.com Message-ID: <38F37611.89A42CA4@fpk.hp.com> Date: Tue, 11 Apr 2000 14:59:29 -0400 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: Simon Nash Cc: Paul Kyzivat , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <9B164B713EE9D211B6DC0090273CEEA926BDC0@bos1.noblenet.com> <38F31E91.62DA5064@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~Kf!!LRO!!?0-e97KX!! I think that the overall issue revolves around deciding which of the interfaces are meant to operate at a "meta" level (Jeff here's your $10 so keep quiet:-)). Things like unmarshaling are obviously at a meta level and hence they are allowed to set values of all fields, 'cause without that they couldn't function. Something like DynAny, at least in some of its usage scenarios seemingly needs to be in a meta level equivalent to that of unmarshaling/marshaling. But then again in other usage scenarios they don't. Assuming that at some point someone will use this stuff on a machine where fine grained protection of this sort can be provided, could this problem be resolved by providing two separate operations, one that allows modification of private fields and another that does not? In systems where fine grained protection is available, those parts of the system that need to do bit twiddling at a meta level could be given access to the more powerful operation, whereas the rest of the world could be given access only to the less powerful? Then again we could postpone doing this until a machine materializes that makes this a really usable feature I suppose. Now for a thing that has been bugging me about this whole "private" thing in IDL. It says in Chapter 3 that "private" annotation directs the language mapping to hide the state from the clients of the value type. Presumably this annotation can be acted upon only by those language mappings which map to languages that have facilities to provide such protection. So even if there were no DynValue operation to allow making these changes to "private" fields, all that I have to do is arrange to get my favorite valuetype constructed in a language environment that does not provide this protection, and have it shipped in to me over IIOP. So at best this protection is dubious in a strict security sense. I think that the approach suggested by Simon below, wherein we include a strict warning about the dangers of constructing DynValues with private state carelessly without heeding the invariants of the type etc. is the best that can be done given the current state of implementation world. In reality, in a heterogeneous system the "private" in valuetype declaration can at best be advisory anyway, even as it is worded in the spec. We already require the Java language mapping to honor this "private" directive. Additionally, we could allow blocking of setting of private fields in the Java environment, thus providing the same level of "protection" in a pure Java/CORBA environment, as is afforded in the Java language. This is done much better using the two operation approach suggested above. Just a bit of loud thinking above..... TAFN, Jishnu. Simon Nash wrote: > > Paul, > I did see your earlier message but I did not respond yesterday > because I was > thinking about your arguments. > > I have a lot of sympathy with most of what you are saying. The part > that > concerns me is your assertion that the contents of a GIOP stream > cannot be > trusted. There certainly are mechanisms like SSL that can ensure > that > the data received is the same as the data sent. And if the sending > system's > integrity can be trusted, that data should be valid. So I disagree > that > every Java valuetype unmarshalling operation should need to carry > the > overhead of performing integrity checking. > > This presumption of integrity applies to a parameter whose declared > type is > a valuetype being sent across the wire. If an any containing a > valuetype > is sent across the wire, then the receiver must explicitly extract > the > valuetype from the any before calling any valuetype methods, and I > agree that > this extraction operation provides an opportunity for integrity > checking. > > As you suggest, this could be handled as an issue of whether the > Java binding > (and other language bindings) should provide a way for running > integrity checking > code on a valuetype language object after it has been constructed by > extraction > from an any (or encapsulation). For example, there could be a > special method > called "validate" which if defined would be called automatically > following the > extraction. Alternatively we could punt and say that since > extraction is a > programmatic operation performed explicitly by a programmer, the > programmer is > responsible for calling an appropriate validation method on the > valuetype > implementation immediately after extraction. > > In any case we should document the potential integrity issues with > setting > private members of a DynValue. > > Simon > > Paul Kyzivat wrote: > > > > I send a message on this subject on Friday that hasn't been > referenced, so > > maybe it got lost. (Or maybe everybody thought I was crazy.) In > any case I > > will try again. > > > > If a language (like Java) is concerned about enforcing the > consistency of > > the valuetype state, then it needs to protect itself when it > receives the > > state from a source it doesn't control. > > > > One such source is an GIOP stream being unmarshalled. You can > never know who > > might have been messing with that data. So, when unmarshalling, > you can > > initialize the private data from the stream, but before completion > there > > should be some means of verifying that the state is valid. This is > true > > whether the stream is via an IIOP connection, or whether it is an > > encapsulation. > > > > (With the PI stuff we have provided a way to encode/decode > encapsulations. > > There is nothing to stop me from encoding a valuetype as an > encapsulation, > > hacking on the bytes in the encapsulation to change private data, > and then > > decoding the encapsulation. It should be possible to do this in > Java as soon > > as there is a PI implementation - perhaps OOC can do it now!) > > > > DynValue is essentially the same - converting a DynValue to a > valuetype is > > equivalent in security risk to decoding an encapsulation > containing a > > valuetype. > > > > So, I think it is fruitless to draw the rules in an attempt to let > Java > > trust what it decodes from a GIOP stream. Better for the Java RTF > to work on > > how to validate the type after it has been decoded. Date: Tue, 11 Apr 2000 19:54:41 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: Paul Kyzivat , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <9B164B713EE9D211B6DC0090273CEEA926BDC3@bos1.noblenet.com> <38F347B7.6AD3B270@hursley.ibm.com> <38F362B4.C316B421@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f?\!!XB^d9Yfed9W,C!! Jishnu, Jishnu Mukerji wrote: > > Simon Nash wrote: > > > > Paul, > > > > Paul Kyzivat wrote: > > > > > > Even in the case of an SSL connection, there is plenty of > opportunity for > > > error. If there are distinct implementations of the valuetype at > the two > > > ends of the conversation, one of them may be incorrect > (intentionally or > > > accidentally). Should the other implementation depend on that > correctness > > > for its own correct functioning? > > > > > SSL implies that the receiver knows the sender's identity. So it > should be > > possible to only accept connections from senders that are known to > be trusted > > and internally secure (no bogus implementations can exist on > them). In this > > case an integrity check could be optimized out. > > One minor nit. SSL by itself does not imply anything like what is > claimed above. An SSL connection > setup with appropriate options (Client Auth) does imply what is > claimed. > Of course that is what I meant to say :-) > So, yes, if a client autheticated SSL connection is setup, and one chooses to trust the > authenticated client, and the entire setup that said client is executing in, then the rest might > follow. Of course the leap from "knowing the sender's identity" to the "correctness of all the code > that s/he is executing" could be a phenomenal one.:-) > If "client" is some random person out there with a laptop, then I share your doubts as to correctness. But "client" in the CORBA sense may be a server machine inside a glasshouse with C2 security and whatever. There are clients that I can trust and clients that I can't... 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, 11 Apr 2000 20:14:52 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <9B164B713EE9D211B6DC0090273CEEA926BDC7@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: YMR!!_dG!!LZ$!!GCLe9 Paul, Paul Kyzivat wrote: > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > In a totally insecure system, no check is needed. Likewise > > in a totally > > secure system. For mixtures, the means to check is needed. > > > SSL implies that the receiver knows the sender's identity. > > So it should be > > possible to only accept connections from senders that are > > known to be trusted > > and internally secure (no bogus implementations can exist on > > them). In this > > case an integrity check could be optimized out. > > So, how do you propose to take advantage of this? > I haven't worked out the details. Checking on every unmarshal can be implemented using a custom valuetype, but not very user-friendly or efficient. RMI-IIOP solves the usability problem by providing the > readObject and defaultReadObject methods, but there is no equivalent for > IDL-to-Java or other language bindings. An interceptor that gets called after > unmarshalling and is passed the unmarshalled data is one possible answer, but the > cost of always calling the interceptor could exceed the cost of always doing > the validation. > Will your code only support totally secure and totally insecure > environments? > > Won't your customers expect you to support environments that are not > totally > secure? > I'm sure they will. And we can do so (not optimally) with custom > unmarshalling. > An example of an environment that is not totally secure is one that uses > DynValue to create a new valuetype, including the private state. Just > because it isn't totally secure doesn't mean it should be banned. It is a > useful thing to have, especially during debugging. > I don't disagree that it may be useful. However, if implementers do use custom valuetypes to provide the extra integrity checking, this will totally destroy the ability to create instances of those types using DynValue. Perhaps DynValue needs to be enhanced to allow it to support custom valuetypes too. Simon > Another example of an environment that is not totally secure is one that > includes code in c++. At least the runtime cannot *guarantee* that a > valuetype is fully consistent. (Perhaps an audit of all the code can > guarantee that, to some degree.) > > Paul -- 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 Subject: RE: Revised proposal for issues 3135 and 3250 Date: Tue, 11 Apr 2000 16:03:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: J9C!!d/+e99_Ce9\E(!! > From: Simon Nash [mailto:nash@hursley.ibm.com] > Perhaps DynValue needs to be enhanced to allow it to support custom > valuetypes too. This seems to be impossible. There is no state defined in IDL or in the typecode, so what would DynValue let you do? And what would it send on the wire? At most, it might be possible to pull the chunks of an unknown custom valuetype off the wire, hold onto them, and send them back out on the wire. Perhaps there could be a DynCustomValue that allowed setting and accessing chunks. But I think we have established that the way chunking works it is impossible to save and replay chunks. So this doesn't fly. Paul X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 11 Apr 2000 16:03:56 -0500 To: Simon Nash From: Steve Vinoski Subject: Re: Revised proposal for issues 3135 and 3250 Cc: orb_revision@omg.org In-Reply-To: <38F3049A.90F13703@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: !CZ!!Fc?!!RDR!![BYd9 At 11:55 AM 4/11/00 +0100, Simon Nash wrote: If you are referring to the original OBV spec, this did not permit construction of valuetypes except via initializers provided by the valuetype implementation. Construction of DynValue from scratch was specifically prohibited in this spec because of the type invariant issue. Simon, please spare me your arguments regarding DynValue -- they are as weak and as pointless as they were when you originally made them in the OBV submitters' meetings. The real problem here, as I originally pointed out during those meetings, is not DynValue -- the *real* problem is that the purveyors of OBV never took the DII and DSI into account when they "designed" their solution to begin with. (You might remember one of those submitters actually asking "What's the DSI?" when I first surfaced the fact that OBV broke DSI applications.) If you start locking down the capabilities of DynValue in the manner you're suggesting, then you are disallowing a whole class of dynamic applications and solutions based on scripting languages from invoking operations that involve valuetypes. Trying to take some moral high ground involving private state initialization and Java security is just a sad slap in the face to those programmers needing truly dynamic programs to solve their distributed computing problems. And from what I see in my day-to-day work, their numbers are growing, not shrinking. Michi's and Jon's DynValue designs fix some of the flagrant OBV omissions regarding the DII and DSI. Please don't try to undo or block their fine work. --steve Date: Wed, 12 Apr 2000 07:01:01 +1000 (EST) From: Michi Henning To: Simon Nash cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38F3049A.90F13703@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: C)#"!Jc=!!3]p!!Q=N!! On Tue, 11 Apr 2000, Simon Nash wrote: > > CORBA also has to work with languages other than Java. > > > CORBA specifies language-neutral semantics. These include the > "private" keyword > in IDL. Either this has reliable CORBA-defined semantics or it > doesn't. > If it truly means "private" only in some languages, then its > semantics are > meaningless and we may as well deprecate it (not that I want to do > this). I'm sorry, but IDL can specify "private" all it likes. There is no practical way to enforce it with current technology. All "private" can be is a scoping mechanism that prevents access via normal language constructs, but it can't prevent access by other means, such as manipulating raw memory. And, as someone else pointed out, even in Java you don't have protection, because I can serialize and deserialize a value and change the serialized representation in between. > And even if my whole system is Java, opening up this DynValue hole > means that any private field in any valuetype may be modified by > anyone > who feels like doing so. So any security/integrity I thought that > Java > has buying me has just gone out the window. I'm sorry, but private members have never been secure, that has always been an illustion. What's to stop me from opening a TCP/IP connection and crafting my own requests that contain faked valuetypes? > > Well, the original spec *did* permit construction of value types, so the > > changes we made were an attempt at preserving the original intent. Of course, > > we could make dynamic construction of valuetypes impossible altogether > > (apart from permitting construction from an existing value type). I'm not > > sure what the ramifications of such a decision would be though. Would this > > be an acceptable thing to do? > > > If you are referring to the original OBV spec, this did not permit construction > of valuetypes except via initializers provided by the valuetype implementation. > Construction of DynValue from scratch was specifically prohibited in this spec > because of the type invariant issue. Yes. And, as I pointed out earlier, permitting construction of only the public members of a value that also has private members is useless. 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 To: Simon Nash cc: Michi Henning , Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: Your message of "Tue, 11 Apr 2000 05:41:28 PDT." <38F3049A.90F13703@hursley.ibm.com> From: Bill Janssen Message-Id: <00Apr11.140837pdt."3432"@watson.parc.xerox.com> Date: Tue, 11 Apr 2000 14:08:44 PDT Content-Type: text X-UIDL: EXG!!'m2!!V@-e9:LK!! > CORBA specifies language-neutral semantics. These include the "private" keyword > in IDL. Either this has reliable CORBA-defined semantics or it doesn't. > If it truly means "private" only in some languages, then its semantics are > meaningless and we may as well deprecate it (not that I want to do this). Yes, I've always thought this was a pretty useless addition to IDL. Bill Sender: jbiggar@corvette.floorboard.com Message-ID: <38F3978A.2EF5988D@floorboard.com> Date: Tue, 11 Apr 2000 14:22:18 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Simon Nash , Michi Henning , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <00Apr11.140837pdt."3432"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :<3!!"Sdd9KT,e9el:!! Bill Janssen wrote: > > > CORBA specifies language-neutral semantics. These include the > "private" keyword > > in IDL. Either this has reliable CORBA-defined semantics or it > doesn't. > > If it truly means "private" only in some languages, then its > semantics are > > meaningless and we may as well deprecate it (not that I want to do > this). > > Yes, I've always thought this was a pretty useless addition to IDL. I wouldn't go so far. It is still useful as an indication to the programmer that these particular variables are part of the "internal state" of the valuetype, and are really only properly accessed via the operations defined on the valuetype. Consider it more a warning like "There are no user-serviceable parts inside this device." :-) Doesn't really stop people from opening the box if they really want to, but it should make them think first. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 12 Apr 2000 07:33:13 +1000 (EST) From: Michi Henning To: Simon Nash cc: Paul Kyzivat , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38F347B7.6AD3B270@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: $>C!!~Smd9IZ9e9<6j!! On Tue, 11 Apr 2000, Simon Nash wrote: > > Even in the case of an SSL connection, there is plenty of opportunity for > > error. If there are distinct implementations of the valuetype at the two > > ends of the conversation, one of them may be incorrect (intentionally or > > accidentally). Should the other implementation depend on that correctness > > for its own correct functioning? > > > SSL implies that the receiver knows the sender's identity. So it should be > possible to only accept connections from senders that are known to be trusted > and internally secure (no bogus implementations can exist on them). In this > case an integrity check could be optimized out. So, what if the sender's ORB has a bug and occasionally marshals something that's not quite right? (Not that this would ever happen in real life... ;-) Any notion of privacy or security for private valuetype members is simply misguided, IMO. There is no real privacy here, only access controls in the implementation language. 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 Date: Wed, 12 Apr 2000 09:01:12 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Simon Nash , Paul Kyzivat , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38F37611.89A42CA4@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 4Ph!!cA>!!p'/e9J-!!! On Tue, 11 Apr 2000, Jishnu Mukerji wrote: > I think that the approach suggested by Simon below, wherein we include a strict warning about the > dangers of constructing DynValues with private state carelessly without heeding the invariants of > the type etc. is the best that can be done given the current state of implementation world. I agree with this. 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 Date: Wed, 12 Apr 2000 09:03:24 +1000 (EST) From: Michi Henning To: Simon Nash cc: Jishnu Mukerji , Paul Kyzivat , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38F374F1.76D16962@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: n+bd9*Zj!!\,]!!>i3e9 On Tue, 11 Apr 2000, Simon Nash wrote: > If "client" is some random person out there with a laptop, then I share your > doubts as to correctness. > > But "client" in the CORBA sense may be a server machine inside a glasshouse > with C2 security and whatever. There are clients that I can trust and clients > that I can't... In that case, I don't need SSL either, do I? Just run a separate network to the server in the glass house... I think these points are pretty much moot anyway. There is no way to enforce private data with current implementation technology. As Jon and others have pointed out, disallowing composition of valuetypes with private data would impact an entire class of applications, so I would suggest that we permit it and add a warning about invariants, as you and Jishnu suggested. 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 Date: Wed, 12 Apr 2000 09:22:45 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Simon Nash , Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <00Apr11.140837pdt."3432"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: A4jd9"T$!!fJjd9`'Ud9 On Tue, 11 Apr 2000, Bill Janssen wrote: > Yes, I've always thought this was a pretty useless addition to IDL. Right. If members a truly private, why announce their existence for the world to see in the IDL? ;-) 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 Date: Wed, 12 Apr 2000 19:18:55 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <9B164B713EE9D211B6DC0090273CEEA926BDCC@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: fS)!!%:2e9;IN!!gmNe9 Paul, Paul Kyzivat wrote: > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > Perhaps DynValue needs to be enhanced to allow it to support > custom > > valuetypes too. > > This seems to be impossible. There is no state defined in IDL or in > the > typecode, so what would DynValue let you do? And what would it send > on the > wire? > The constraints on the values of private members of non-custom > valuetypes are not defined in IDL either, but I didn't get any support for my > assertion that this made it unsafe for DynValue users to be given complete > control over setting this data. The assumption was that the DynValue user > knew enough about the implementation to be able to get this right. So, by > analogy, the DynCustomValue user can be presumed to know enough about the > custom marshaling implementation to be able to put exactly the right data > into the DynCustomValue to be custom unmarshaled by the actual valuetype > implementation. > At most, it might be possible to pull the chunks of an unknown custom > valuetype off the wire, hold onto them, and send them back out on the wire. > Perhaps there could be a DynCustomValue that allowed setting and accessing > chunks. > > But I think we have established that the way chunking works it is impossible > to save and replay chunks. So this doesn't fly. > This was not what I had in mind. My idea was to open up DynCustomValue to allow all the DataInputStream and DataOutputStream operations to be invoked. 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: Wed, 12 Apr 2000 19:29:20 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Bill Janssen , Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: aMLe9gO_!!8'Md9kb@e9 Michi, Michi Henning wrote: > > On Tue, 11 Apr 2000, Bill Janssen wrote: > > > Yes, I've always thought this was a pretty useless addition to > IDL. > > Right. If members a truly private, why announce their existence for > the > world to see in the IDL? ;-) > Because the marshaler/unmarshaler need this information, so it has to > be declared somewhere. 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 From: Paul Kyzivat To: orb_revision@omg.org Subject: RE: Revised proposal for issues 3135 and 3250 Date: Wed, 12 Apr 2000 15:41:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: From: Simon Nash [mailto:nash@hursley.ibm.com] > > > Perhaps DynValue needs to be enhanced to allow it to > > > support custom valuetypes too. > > > > This seems to be impossible. There is no state defined in > IDL or in the > > typecode, so what would DynValue let you do? And what would > it send on the > > wire? > > > The constraints on the values of private members of > non-custom valuetypes > are not defined in IDL either, but I didn't get any support > for my assertion > that this made it unsafe for DynValue users to be given > complete control > over setting this data. There is a difference. In the case of a regular valuetype, the marshalling is driven off the declared state. In the case of custom valuetypes, there is no reason to believe that this is true - it is quite likely that the marshalling for a custom valuetype will in fact be driven off state that isn't declared at all in idl. I guess DynCustomValue could operate just like DynValue, providing access to the declared members, but this would not necessarily serve any purpose. > The assumption was that the DynValue > user knew > enough about the implementation to be able to get this right. > So, by analogy, > the DynCustomValue user can be presumed to know enough about > the custom > marshaling implementation to be able to put exactly the right > data into the > DynCustomValue to be custom unmarshaled by the actual > valuetype implementation. Even if the user knows everything, the DynCustomValue cannot provide a way to initialize the undeclared state. > This was not what I had in mind. My idea was to open up > DynCustomValue to allow > all the DataInputStream and DataOutputStream operations to be > invoked. To be invoked by what? There is no guarantee (or even likelihood) that an actual implemenation of the custom valuetype or its marshaller is available to the user of DynCustomValue. Even if one was available, it would expect to operate off of an instance of the valuetype, not the DynCustomValue. There is no obvious way for the DynCustomValue to transform its representation into the actual custom valuetype. === I have the impression we are misunderstanding each other because of drastically different implementation perspectives. But of course that simply indicates inadequacies in the spec, which should be understandable from the perspective of different language mappings. Paul Date: Thu, 13 Apr 2000 07:27:43 +1000 (EST) From: Michi Henning To: Simon Nash cc: Bill Janssen , Jonathan Biggar , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 In-Reply-To: <38F4C080.626E9A8C@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?Jed92<,e95_jd9H > Right. If members a truly private, why announce their existence for the > > world to see in the IDL? ;-) > > > Because the marshaler/unmarshaler need this information, so it has to be > declared somewhere. I know that Simon, and I wasn't entirely serious. It's a bit like C++, which puts the private section of a class into its public header file. In both cases, the dichotomy is caused by less-than-ideal separation of implementation and interface. 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: Jeffrey Mischkinsky Message-Id: <200004141826.LAA18063@wheel.dcn.davis.ca.us> Subject: Re: Revised proposal for issues 3135 and 3250 To: michi@ooc.com.au (Michi Henning) Date: Fri, 14 Apr 2000 11:26:35 -0700 (PDT) Cc: nash@hursley.ibm.com (Simon Nash), paulk@roguewave.com (Paul Kyzivat), orb_revision@omg.org In-Reply-To: from "Michi Henning" at Apr 12, 2000 07:33:13 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4A>!!];ed9Z#E!!?:=!! 'Michi Henning' writes: > > On Tue, 11 Apr 2000, Simon Nash wrote: > > > > Even in the case of an SSL connection, there is plenty of > opportunity for > > > error. If there are distinct implementations of the valuetype at > the two > > > ends of the conversation, one of them may be incorrect > (intentionally or > > > accidentally). Should the other implementation depend on that > correctness > > > for its own correct functioning? > > > > > SSL implies that the receiver knows the sender's identity. So it > should be > > possible to only accept connections from senders that are known to > be trusted > > and internally secure (no bogus implementations can exist on > them). In this > > case an integrity check could be optimized out. > > So, what if the sender's ORB has a bug and occasionally marshals > something > that's not quite right? (Not that this would ever happen in real > life... ;-) > > Any notion of privacy or security for private valuetype members is > simply > misguided, IMO. There is no real privacy here, only access controls > in the implementation language. I think Michi is correct here. Security has nothing to do with this. We spent lots of time discussion the real meaning of public/private. At think at best, it's a "hint" which the language mapping should try to implement as best as it can. As has been pointed out, any environment which allows access to arbitrary memory in one's address space is not going to be able to absolutely protect anything. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Sun, 16 Apr 2000 13:14:43 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <9B164B713EE9D211B6DC0090273CEEA926BDD4@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -:Zd9XM(!!J#:e9B'ed9 Status: U Paul, Paul Kyzivat wrote: > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > > > Perhaps DynValue needs to be enhanced to allow it to > > > > support custom valuetypes too. > > > > > > This seems to be impossible. There is no state defined in > > IDL or in the > > > typecode, so what would DynValue let you do? And what would > > it send on the > > > wire? > > > > > The constraints on the values of private members of > > non-custom valuetypes > > are not defined in IDL either, but I didn't get any support > > for my assertion > > that this made it unsafe for DynValue users to be given > > complete control > > over setting this data. > > There is a difference. In the case of a regular valuetype, the marshalling > is driven off the declared state. In the case of custom valuetypes, there is > no reason to believe that this is true - it is quite likely that the > marshalling for a custom valuetype will in fact be driven off state that > isn't declared at all in idl. > The only difference is that for non-custom valuetypes, the shape of the valuetype's marshalled state is known, but not the invariants that govern the relationships between different parts of that state. For a custom valuetype, neither the shape nor the invariants is known. I don't think this makes much difference in practice. In both cases, if the creator of a DynValue or DynCustomValue gets things wrong, attempting to convert the DynValue or DynCustomValue into a valuetype implementation instance will cause serious problems. > I guess DynCustomValue could operate just like DynValue, providing access to > the declared members, but this would not necessarily serve any purpose. > Agreed. That is not what I'm suggesting. > > The assumption was that the DynValue > > user knew > > enough about the implementation to be able to get this right. > > So, by analogy, > > the DynCustomValue user can be presumed to know enough about > > the custom > > marshaling implementation to be able to put exactly the right > > data into the > > DynCustomValue to be custom unmarshaled by the actual > > valuetype implementation. > > Even if the user knows everything, the DynCustomValue cannot provide a way > to initialize the undeclared state. > The undeclared state can be written to the DynCustomValue using the DataOutputStream operations. This assumes that the creator of a DynCustomValue knows what the undeclared state is. > > This was not what I had in mind. My idea was to open up > > DynCustomValue to allow > > all the DataInputStream and DataOutputStream operations to be invoked. > > To be invoked by what? > They would be invoked by the creator of the DynCustomValue. The assumption is that whoever is creating this knows about the custom valuetype that the DynCustomValue represents and knows what its marshalled form is. This seems no different than requiring the creator of a DynValue to know about the invariants that govern correct setting of the private members. > There is no guarantee (or even likelihood) that an actual implemenation of > the custom valuetype or its marshaller is available to the user of > DynCustomValue. > The actual implementation does not need to be available. However, knowledge about the marshalled form does need to be available. This is not too far fetched. For example, the JDK documentation lists the marshalled form of every serializable class, including those that are custom marshalled. > Even if one was available, it would expect to operate off of an instance of > the valuetype, not the DynCustomValue. There is no obvious way for the > DynCustomValue to transform its representation into the actual custom > valuetype. > A DynCustomValue would be converted into a valuetype by the usual "extract from any" operation. The implementation of this is effectively the same as unmarshalling the valuetype data. This is how IBM's Java ORB (and I suspect others) transforms an any into a valuetype. > === > > I have the impression we are misunderstanding each other because of > drastically different implementation perspectives. But of course that simply > indicates inadequacies in the spec, which should be understandable from the > perspective of different language mappings. > I hope my comments above have clarified how I would expect this to work and be used. 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, 17 Apr 2000 02:38:56 +0100 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: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <4.3.2.20000411154604.03bf36c0@mail.boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~d0e9'm > At 11:55 AM 4/11/00 +0100, Simon Nash wrote: > >If you are referring to the original OBV spec, this did not permit > >construction > >of valuetypes except via initializers provided by the valuetype > >implementation. > >Construction of DynValue from scratch was specifically prohibited in this spec > >because of the type invariant issue. > > Simon, please spare me your arguments regarding DynValue -- they are as > weak and as pointless as they were when you originally made them in the OBV > submitters' meetings. The real problem here, as I originally pointed out > during those meetings, is not DynValue -- the *real* problem is that the > purveyors of OBV never took the DII and DSI into account when they > "designed" their solution to begin with. (You might remember one of those > submitters actually asking "What's the DSI?" when I first surfaced the fact > that OBV broke DSI applications.) > > If you start locking down the capabilities of DynValue in the manner you're > suggesting, then you are disallowing a whole class of dynamic applications > and solutions based on scripting languages from invoking operations that > involve valuetypes. Trying to take some moral high ground involving private > state initialization and Java security is just a sad slap in the face to > those programmers needing truly dynamic programs to solve their distributed > computing problems. And from what I see in my day-to-day work, their > numbers are growing, not shrinking. > > Michi's and Jon's DynValue designs fix some of the flagrant OBV omissions > regarding the DII and DSI. Please don't try to undo or block their fine work. > > --steve -- 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: Sun, 16 Apr 2000 13:31:55 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Mischkinsky CC: Michi Henning , Paul Kyzivat , orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <200004141826.LAA18063@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: eaNe93'[d9VlTd9]d;!! Status: U Jeff, Jeffrey Mischkinsky wrote: > > 'Michi Henning' writes: > > > > On Tue, 11 Apr 2000, Simon Nash wrote: > > > > > > Even in the case of an SSL connection, there is plenty of opportunity for > > > > error. If there are distinct implementations of the valuetype at the two > > > > ends of the conversation, one of them may be incorrect (intentionally or > > > > accidentally). Should the other implementation depend on that correctness > > > > for its own correct functioning? > > > > > > > SSL implies that the receiver knows the sender's identity. So it should be > > > possible to only accept connections from senders that are known to be trusted > > > and internally secure (no bogus implementations can exist on them). In this > > > case an integrity check could be optimized out. > > > > So, what if the sender's ORB has a bug and occasionally marshals something > > that's not quite right? (Not that this would ever happen in real life... ;-) > > > > Any notion of privacy or security for private valuetype members is simply > > misguided, IMO. There is no real privacy here, only access controls > > in the implementation language. > > I think Michi is correct here. Security has nothing to do with this. > We spent lots of time discussion the real meaning of public/private. > > At think at best, it's a "hint" which the language mapping should try to > implement as best as it can. > > As has been pointed out, any environment which allows access to arbitrary > memory in one's address space is not going to be able to absolutely protect > anything. > True, but I think it is very unfortunate that those languages and/or systems that are able to prevent this arbitrary access can have their integrity compromised by this CORBA "feature." 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 From: Paul Kyzivat To: orb_revision@omg.org Subject: RE: Revised proposal for issues 3135 and 3250 Date: Tue, 18 Apr 2000 11:33:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Yk;!!U]L!!<9Pd9ShX!! > From: Simon Nash [mailto:nash@hursley.ibm.com] > > I guess DynCustomValue could operate just like DynValue, > > providing access to the declared members, but this would not > > necessarily serve any purpose. > > > Agreed. That is not what I'm suggesting. Then I'm still trying to understand what you are suggesting. It gets slightly clearer below, but not clear enough. > > Even if the user knows everything, the DynCustomValue > > cannot provide a way to initialize the undeclared state. > > > The undeclared state can be written to the DynCustomValue using the > DataOutputStream operations. This assumes that the creator of a > DynCustomValue knows what the undeclared state is. > > > > This was not what I had in mind. My idea was to open up > > > DynCustomValue to allow > > > all the DataInputStream and DataOutputStream operations > > > to be invoked. > > > > To be invoked by what? > > > They would be invoked by the creator of the DynCustomValue. > The assumption > is that whoever is creating this knows about the custom valuetype that > the DynCustomValue represents and knows what its marshalled form is. > This seems no different than requiring the creator of a > DynValue to know > about the invariants that govern correct setting of the > private members. Are you suggesting that DynCustomValue somehow provide a DataOutputStream (and presumably a DataInputStream as well) that is used to populate and access it? That is certainly an innovative idea. But at the least it would introduce a lot of complexity. (What is the state *while* the stream is being written? When is the state complete?) > > > There is no guarantee (or even likelihood) that an actual > implemenation of > > the custom valuetype or its marshaller is available to the user of > > DynCustomValue. > > > The actual implementation does not need to be available. > However, knowledge > about the marshalled form does need to be available. This is not too > far fetched. For example, the JDK documentation lists the > marshalled form > of every serializable class, including those that are custom > marshalled. > > > Even if one was available, it would expect to operate off > of an instance of > > the valuetype, not the DynCustomValue. There is no obvious > way for the > > DynCustomValue to transform its representation into the > actual custom > > valuetype. > > > A DynCustomValue would be converted into a valuetype by the > usual "extract > from any" operation. The implementation of this is > effectively the same as > unmarshalling the valuetype data. This is how IBM's Java ORB > (and I suspect > others) transforms an any into a valuetype. What would the to_any() operation do on DynCustomValue? It must produce an any that has the proper typecode, that can be marshalled, and that supports extraction. > I hope my comments above have clarified how I would expect > this to work and be used. Yes, they have helped some. This is still some way from a full definition of how this might work, but possibly a step in the right direction. Paul P.S. Thanks for resending your messages to me after they bounced. Somebody did a poor job of reconfiguring our our network last weekend. From: Paul Kyzivat To: orb_revision@omg.org Subject: RE: Revised proposal for issues 3135 and 3250 Date: Tue, 18 Apr 2000 11:41:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: aZK!!e~_d90ecd9PQ>e9 > From: Simon Nash [mailto:nash@hursley.ibm.com] > > As has been pointed out, any environment which allows > access to arbitrary > > memory in one's address space is not going to be able to > absolutely protect > > anything. > > > True, but I think it is very unfortunate that those languages > and/or systems > that are able to prevent this arbitrary access can have their > integrity compromised by this CORBA "feature." You have the same problem with regular RMI. The language runtime can only control what is in its sphere of influence. Once you let something in or out you lose control. If you want to trust invariants, then you must verify them for anything that enters your control. The flaw in valuetypes was in not providing a way to do this. That is something that ought to be addressed. CORBA IDL for valuetypes doesn't even provide a way to declare invariants on the private state of valuetypes, so you can't expect your language specific notion of those invariants to be preserved more widely. As long as you treat DynValue as something outside your control that must be verified when converted to a valuetype then you have lost nothing. Paul Date: Thu, 20 Apr 2000 03:01:54 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: orb_revision@omg.org Subject: Re: Revised proposal for issues 3135 and 3250 References: <9B164B713EE9D211B6DC0090273CEEA926BDF8@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: JpZd9~V6!!S/id9 > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > > As has been pointed out, any environment which allows > > access to arbitrary > > > memory in one's address space is not going to be able to > > absolutely protect > > > anything. > > > > > True, but I think it is very unfortunate that those languages > > and/or systems > > that are able to prevent this arbitrary access can have their > > integrity compromised by this CORBA "feature." > > You have the same problem with regular RMI. > > The language runtime can only control what is in its sphere of influence. > Once you let something in or out you lose control. > > If you want to trust invariants, then you must verify them for anything that > enters your control. The flaw in valuetypes was in not providing a way to do > this. That is something that ought to be addressed. > > CORBA IDL for valuetypes doesn't even provide a way to declare invariants on > the private state of valuetypes, so you can't expect your language specific > notion of those invariants to be preserved more widely. > > As long as you treat DynValue as something outside your control that must be > verified when converted to a valuetype then you have lost nothing. > > Paul -- 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 Subject: RE: Revised proposal for issues 3135 and 3250 Date: Thu, 20 Apr 2000 10:01:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: * From: Simon Nash [mailto:nash@hursley.ibm.com] > OK, we are agreed that this is the best way to deal with the invariant > issue. Do you have any suggestions for how the verification > step would > operate? Is this something for every language binding to define, or a > core facility? My first reaction is to say that this should be language-binding specific, because there may already be natural places in the language bindings to add it. But I am interested to hear what others think, because I don't feel I have an adequate perspective on the issue. In C++, there could be a virtual function (perhaps _verify_unmarshal) defined in ValueBase with a default implementation that does nothing. This would complement the create_for_unmarshal operation on the factory. Paul Sender: jbiggar@corvette.floorboard.com Message-ID: <38FF874E.67F5D9E0@floorboard.com> Date: Thu, 20 Apr 2000 15:40:14 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Third revision of proposal for issues 3135 and 3250 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [UFe9lA:e9AkG!!ZAKe9 Issue 3135: valuebox and DynAny Issue 3250: Null valuetypes not supported by DynValue [I'm trying to get this ready for vote next week. The major question I have is whether the change in inheritence (DynValue now inherits from DynValueCommon) is acceptable to the majority of RTF members. I know that Simon doesn't like it already. If you don't like it speak up. If enough do, I'll rewrite it and remove the inheritence and just duplication operations between DynValue and DynValueBox. Jishnu: if no quorum objects and I haven't updated this by the next vote, go ahead and add it to the vote.] Proposal for Issues 3135 and 3250: 1. Replace the IDL for DynValue in 9.2 with: interface DynValueCommon : DynAny { boolean is_null(); void set_to_null(); void set_to_value(); }; interface DynValue : DynValueCommon { FieldName current_member_name() raises(TypeMismatch, InvalidValue); CORBA::TCKind current_member_kind() raises(TypeMismatch, InvalidValue); NameValuePairSeq get_members() raises(InvalidValue); void set_members(in NameValuePairSeq value) raises(TypeMismatch, InvalidValue); NameDynAnyPairSeq get_members_as_dyn_any() raises(InvalidValue); void set_members_as_dyn_any(in NameDynAnyPairSeq value) raises(TypeMismatch, InvalidValue); }; interface DynValueBox : DynValueCommon { any get_boxed_value() raises(InvalidValue); void set_boxed_value(in any boxed) raises(TypeMismatch); DynAny get_boxed_value_as_dyn_any() raises(InvalidValue); void set_boxed_value_as_dyn_any(in DynAny boxed) raises(TypeMismatch); }; ------------------------------------------------------------------------------ 2. Change the complex type initialization bullet in section 9.2.2 for DynValue from: o For DynValue, the members are initialized as for DynStruct. to: o For DynValue and DynValueBox, initialize to a null value ------------------------------------------------------------------------------ 3. Replace section 9.2.10 with: 9.2.10 The DynValueCommon interface DynValueCommon provides operations supported by both the DynValue and DynValueBox interfaces. [Insert appropriate IDL from above here.] boolean is_null(); The is_null operation returns TRUE if the DynValueCommon represents a null valuetype. void set_to_null(); The set_to_null() operation changes the representation of a DynValueCommon to a null valuetype. void set_to_value(); If the DynValueCommon represents a null valuetype, then set_to_value() replaces it with a newly constructed value, with its components initialized to default values as in DynAnyFactory::create_dyn_any_from_type_code. If the DynValueCommon represents a non-null valuetype, then this operation has no effect. 9.2.11 The DynValue interface DynValue objects are associated with non-boxed valuetypes. [Insert appropriate IDL from above here.] The DynValue interface can represent both null and non-null valuetypes. For a DynValue representing a non-null valuetype, the DynValue's components comprise the public and private members of the valuetype, including those inherited from concrete base valuetypes, in the order of definition. A DynValue representing a null valuetype has no components and a current position of -1. The remaining operations on the DynValue interface generally have equivalent semantics to the same operations on DynStruct. When invoked on a DynValue representing a null valuetype, get_members and get_members_as_dyn_any raise InvalidValue. When invoked on a DynValue representing a null valuetype, set_members and set_members_as_dyn_any convert the DynValue to a non-null valuetype. 9.2.12 The DynValueBox interface DynValueBox objects are associated with boxed valuetypes. [Insert appropriate IDL from above here.] The DynValueBox interface can represent both null and non-null valuetypes. For a DynValueBox representing a non-null valuetype, the DynValueBox has a single component of the boxed type. A DynValueBox representing a null valuetype has no components and a current position of -1. any get_boxed_value() raises(InvalidValue); The get_boxed_value operation returns the boxed value as an any. If the DynBoxedValue represents a null valuetype, the operation raises InvalidValue. void set_boxed_value(in any boxed) raises(TypeMismatch); The set_boxed_value replaces the boxed value with the specified value. If the DynBoxedValue represents a null valuetype, it is converted to a non-null value. The get_boxed_value_as_dyn_any and set_boxed_value_as_dyn_any have the same semantics as their any counterparts, but accept and return values of type DynAny instead of any. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sat, 22 Apr 2000 08:03:02 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: Third revision of proposal for issues 3135 and 3250 References: <38FF874E.67F5D9E0@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !`)e9I+Qe9F`od91Bfd9 Jon, In the text for 9.2.11 that refers to private members, please add a warning that setting private members may enadanger the health of your valuetypes, as agreed in earlier discussion. I think we should not proceed with this vote until we have clarified whether these "set member" operations are changing the state of a real valuetype implementation object, as you suggested in the discussions on issue 3205. I would be strongly opposed to this semantic. I will be on vacation until May 2, with no access to email. Simon Jonathan Biggar wrote: > > Issue 3135: valuebox and DynAny > Issue 3250: Null valuetypes not supported by DynValue > > [I'm trying to get this ready for vote next week. The major question I > have is whether the change in inheritence (DynValue now inherits from > DynValueCommon) is acceptable to the majority of RTF members. I know > that Simon doesn't like it already. If you don't like it speak up. If > enough do, I'll rewrite it and remove the inheritence and just > duplication operations between DynValue and DynValueBox. > > Jishnu: if no quorum objects and I haven't updated this by the next > vote, go ahead and add it to the vote.] > > Proposal for Issues 3135 and 3250: > > 1. Replace the IDL for DynValue in 9.2 with: > > interface DynValueCommon : DynAny { > > boolean is_null(); > > void set_to_null(); > > void set_to_value(); > > }; > > interface DynValue : DynValueCommon { > > FieldName current_member_name() > raises(TypeMismatch, InvalidValue); > > CORBA::TCKind current_member_kind() > raises(TypeMismatch, InvalidValue); > > NameValuePairSeq get_members() > raises(InvalidValue); > > void set_members(in NameValuePairSeq value) > raises(TypeMismatch, InvalidValue); > > NameDynAnyPairSeq get_members_as_dyn_any() > raises(InvalidValue); > > void set_members_as_dyn_any(in NameDynAnyPairSeq value) > raises(TypeMismatch, InvalidValue); > > }; > > interface DynValueBox : DynValueCommon { > any get_boxed_value() > raises(InvalidValue); > > void set_boxed_value(in any boxed) raises(TypeMismatch); > > DynAny get_boxed_value_as_dyn_any() > raises(InvalidValue); > > void set_boxed_value_as_dyn_any(in DynAny boxed) > raises(TypeMismatch); > > }; > > ------------------------------------------------------------------------------ > 2. Change the complex type initialization bullet in section 9.2.2 for > DynValue from: > > o For DynValue, the members are initialized as for DynStruct. > > to: > > o For DynValue and DynValueBox, initialize to a null value > > ------------------------------------------------------------------------------ > 3. Replace section 9.2.10 with: > > 9.2.10 The DynValueCommon interface > > DynValueCommon provides operations supported by both the DynValue and > DynValueBox interfaces. > > [Insert appropriate IDL from above here.] > > boolean is_null(); > > The is_null operation returns TRUE if the DynValueCommon represents a > null valuetype. > > void set_to_null(); > > The set_to_null() operation changes the representation of a > DynValueCommon to a null valuetype. > > void set_to_value(); > > If the DynValueCommon represents a null valuetype, then set_to_value() > replaces it with a newly constructed value, with its components > initialized to default values as in > DynAnyFactory::create_dyn_any_from_type_code. If the > DynValueCommon represents a non-null valuetype, then this operation has > no effect. > > 9.2.11 The DynValue interface > > DynValue objects are associated with non-boxed valuetypes. > > [Insert appropriate IDL from above here.] > > The DynValue interface can represent both null and non-null valuetypes. > For a DynValue representing a non-null valuetype, the DynValue's > components comprise the public and private members of the valuetype, > including those inherited from concrete base valuetypes, in the order of > definition. A DynValue representing a null valuetype has no components > and a current position of -1. > > The remaining operations on the DynValue interface generally have > equivalent semantics to the same operations on DynStruct. When invoked > on a DynValue representing a null valuetype, get_members and > get_members_as_dyn_any raise InvalidValue. When invoked on a DynValue > representing a null valuetype, set_members and set_members_as_dyn_any > convert the DynValue to a non-null > valuetype. > > 9.2.12 The DynValueBox interface > > DynValueBox objects are associated with boxed valuetypes. > > [Insert appropriate IDL from above here.] > > The DynValueBox interface can represent both null and non-null > valuetypes. For a DynValueBox representing a non-null valuetype, the > DynValueBox has a single component of the boxed type. A DynValueBox > representing a null valuetype has no components and a current position > of -1. > > any get_boxed_value() > raises(InvalidValue); > > The get_boxed_value operation returns the boxed value as an any. If the > DynBoxedValue represents a null valuetype, the operation raises > InvalidValue. > > void set_boxed_value(in any boxed) > raises(TypeMismatch); > > The set_boxed_value replaces the boxed value with the specified value. > If the DynBoxedValue represents a null valuetype, it is converted to a > non-null value. > > The get_boxed_value_as_dyn_any and set_boxed_value_as_dyn_any have the > same semantics as their any counterparts, but accept and return values > of type DynAny instead of any. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- 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: jon@corvette.floorboard.com Message-ID: <39038C82.B1717C8D@floorboard.com> Date: Sun, 23 Apr 2000 16:51:30 -0700 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: orb_revision@omg.org Subject: Re: Third revision of proposal for issues 3135 and 3250 References: <38FF874E.67F5D9E0@floorboard.com> <39014EA6.D1A629@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4$od96>6e9RFl!!>ZQ!! Simon Nash wrote: > > Jon, > In the text for 9.2.11 that refers to private members, please add a > warning that setting private members may enadanger the health of your > valuetypes, as agreed in earlier discussion. Can do. How about: "Warning: indiscriminantly changing the contents of private valuetype members can cause the valuetype implementation to break by violating internal constraints. Access to private members is provided to support such activities as ORB bridging and debugging and should not be used to arbitrarily violate the encapsulation of the valuetype. > I think we should not proceed with this vote until we have clarified > whether these "set member" operations are changing the state of a real > valuetype implementation object, as you suggested in the discussions > on issue 3205. I would be strongly opposed to this semantic. I would also prefer to come up with a solution that meets the requirements and does not force ORBs to implement DynValue using the semantic I have identified. However, we do need a solution to the problem. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org