Issue 3459: DynValue & custom valuetypes (corba-rtf) Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com) Nature: Uncategorized Issue Severity: Summary: The CORBA 2.3.1 specification does not cover the interaction between the DynValue interface and custom valuetypes. I frankly don't see any way that the DynValue interface can possibly correctly handle a custom valuetype when the ORB does not have a factory for the type. It is theoretically possible for DynValue to properly work with a known custom type, but the implementation strategy could not be based on parsing the marshalled form of the valuetype. So, there are two issues that need to be addressed: 1. Should DynValue handle custom valuetypes at all? 2. For the set of custom valuetypes that it cannot handle, what exceptions should be raised by each operations? Resolution: Deferred to next RTF Revised Text: Actions taken: March 25, 2000: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== Sender: jon@corvette.floorboard.com Message-ID: <38DD8D3C.6ACF1BFB@floorboard.com> Date: Sat, 25 Mar 2000 20:08:28 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org, issues@omg.org Subject: DynValue & custom valuetypes Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: F?4!!d@o!!)ikd9p(-e9 The CORBA 2.3.1 specification does not cover the interaction between the DynValue interface and custom valuetypes. I frankly don't see any way that the DynValue interface can possibly correctly handle a custom valuetype when the ORB does not have a factory for the type. It is theoretically possible for DynValue to properly work with a known custom type, but the implementation strategy could not be based on parsing the marshalled form of the valuetype. So, there are two issues that need to be addressed: 1. Should DynValue handle custom valuetypes at all? 2. For the set of custom valuetypes that it cannot handle, what exceptions should be raised by each operations? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 07 May 2001 16:30:05 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 3459 discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: S(E!!W_Q!!9BSd98_M!! Issue 3459: DynValue & custom valuetypes (orb_revision) Click here for this issue's archive. Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: The CORBA 2.3.1 specification does not cover the interaction between the DynValue interface and custom valuetypes. I frankly don't see any way that the DynValue interface can possibly correctly handle a custom valuetype when the ORB does not have a factory for the type. It is theoretically possible for DynValue to properly work with a known custom type, but the implementation strategy could not be based on parsing the marshalled form of the valuetype. So, there are two issues that need to be addressed: 1. Should DynValue handle custom valuetypes at all? 2. For the set of custom valuetypes that it cannot handle, what exceptions should be raised by each operations? _______________________________________________________________________ Here is my strawman proposal: Answer to 1: No. Answer to 2: Raise an already existing exception, and if none are defined let us define a new minor code for BAD_PARAM, so as to keep the basic interfaces the same. Jon, what are the operations that would be affected by this? Could you put together a list so that we can address them? Any comments on this approach? Simon? Thanks, Jishnu. X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from corvette.floorboard.com (64.121.176.53) by hobbit.omg.org asmtp(1.0) id 6430; Mon, 07 May 2001 17:24:34 -0400 (EDT) Received: from floorboard.com ([209.111.74.254]) by corvette.floorboard.com (8.9.3+Sun/8.8.8) with ESMTP id OAA10113 for ; Mon, 7 May 2001 14:19:26 -0700 (PDT) Sender: jon@corvette.floorboard.com Message-ID: <3AF7116E.B4DDBB73@floorboard.com> Date: Mon, 07 May 2001 14:19:42 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Re: Issue 3459 discussion References: <3AF705CD.1BB8178F@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,MGe94U)!!R5(!!3PS!! Jishnu Mukerji wrote: > > Issue 3459: DynValue & custom valuetypes (orb_revision) > > Click here for this issue's archive. > Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) > Nature: Uncategorized Issue > Severity: > Summary: The CORBA 2.3.1 specification does not cover the interaction > between the > DynValue interface and custom valuetypes. > > I frankly don't see any way that the DynValue interface can possibly > correctly handle a custom valuetype when the ORB does not have a factory > for the type. It is theoretically possible for DynValue to properly > work with a known custom type, but the implementation strategy could not > be based on parsing the marshalled form of the valuetype. > > So, there are two issues that need to be addressed: > > 1. Should DynValue handle custom valuetypes at all? > > 2. For the set of custom valuetypes that it cannot handle, what > exceptions should be raised by each operations? > > _______________________________________________________________________ > > Here is my strawman proposal: > > Answer to 1: No. > > Answer to 2: Raise an already existing exception, and if none are > defined let us define a new minor code for BAD_PARAM, so as to keep the > basic interfaces the same. > > Jon, what are the operations that would be affected by this? Could you > put together a list so that we can address them? > > Any comments on this approach? Simon? I have an idea that might change the answer to question 1 to yes. Can you put this on hold while I complete my DynAny proposals? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 08 May 2001 17:24:55 +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: jishnu_mukerji@hp.com CC: orb_revision@omg.org Subject: Re: Issue 3459 discussion References: <3AF705CD.1BB8178F@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /R/!!_;V!!]7Me9:aN!! Jishnu, Jishnu Mukerji wrote: > > Issue 3459: DynValue & custom valuetypes (orb_revision) > > Click here for this issue's archive. > Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) > Nature: Uncategorized Issue > Severity: > Summary: The CORBA 2.3.1 specification does not cover the interaction > between the > DynValue interface and custom valuetypes. > > I frankly don't see any way that the DynValue interface can possibly > correctly handle a custom valuetype when the ORB does not have a factory > for the type. It is theoretically possible for DynValue to properly > work with a known custom type, but the implementation strategy could not > be based on parsing the marshalled form of the valuetype. > > So, there are two issues that need to be addressed: > > 1. Should DynValue handle custom valuetypes at all? > > 2. For the set of custom valuetypes that it cannot handle, what > exceptions should be raised by each operations? > > _______________________________________________________________________ > > Here is my strawman proposal: > > Answer to 1: No. > > Answer to 2: Raise an already existing exception, and if none are > defined let us define a new minor code for BAD_PARAM, so as to keep the > basic interfaces the same. > > Jon, what are the operations that would be affected by this? Could you > put together a list so that we can address them? > > Any comments on this approach? Simon? > It might be possible to define some way for DynValue to handle these. For example, they could have an operation to return a DataInputStream that client code could unmarshal, and another operation that returns a DataOutputStream into which an updated value could be marshalled. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 10 May 2001 15:24:51 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA 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: Issue 3459 discussion References: <3AF705CD.1BB8178F@hp.com> <3AF7116E.B4DDBB73@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: c > Jishnu Mukerji wrote: > > > > Issue 3459: DynValue & custom valuetypes (orb_revision) > > > > Click here for this issue's archive. > > Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: The CORBA 2.3.1 specification does not cover the interaction > > between the > > DynValue interface and custom valuetypes. > > > > I frankly don't see any way that the DynValue interface can possibly > > correctly handle a custom valuetype when the ORB does not have a factory > > for the type. It is theoretically possible for DynValue to properly > > work with a known custom type, but the implementation strategy could not > > be based on parsing the marshalled form of the valuetype. > > > > So, there are two issues that need to be addressed: > > > > 1. Should DynValue handle custom valuetypes at all? > > > > 2. For the set of custom valuetypes that it cannot handle, what > > exceptions should be raised by each operations? > > > > _______________________________________________________________________ > > > > Here is my strawman proposal: > > > > Answer to 1: No. > > > > Answer to 2: Raise an already existing exception, and if none are > > defined let us define a new minor code for BAD_PARAM, so as to keep the > > basic interfaces the same. > > > > Jon, what are the operations that would be affected by this? Could you > > put together a list so that we can address them? > > > > Any comments on this approach? Simon? > > I have an idea that might change the answer to question 1 to yes. Can > you put this on hold while I complete my DynAny proposals? OK, we'll hold off on that then. BTW, if you want the DynAny resolutions to get into the first report from this RTF in July, then you better get cracking on the proposals. There are at most two, perhaps 3 more votes to go before then. Thanks, Jishnu.