Issue 1588: Contents of MultiComponent component an encapsulation? (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: I can"t find any text in the CORBA 2.2 spec which says explicitly whether the "component_data" field of IOP::TaggedComponent is actually an encapsulation, or something else. Why don"t we define a typedef "Encapsulation" for "sequence<octet>", and use it in the IDL for those octet sequences which are really encapsulations? Resolution: :TaggedComponent is actually Revised Text: Actions taken: June 29, 1998: received issue February 17, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Sender: Bill Janssen From: Bill Janssen To: interop@omg.org Subject: contents of MultiComponent component an encapsulation? Date: Fri, 26 Jun 1998 22:11:05 PDT I can't find any text in the CORBA 2.2 spec which says explicitly whether the "component_data" field of IOP::TaggedComponent is actually an encapsulation, or something else. Why don't we define a typedef "Encapsulation" for "sequence", and use it in the IDL for those octet sequences which are really encapsulations? Bill Return-Path: Date: Sat, 27 Jun 1998 10:37:35 -0700 From: "Jon Goldberg" To: Bill Janssen CC: interop@omg.org Subject: Re: contents of MultiComponent component an encapsulation? References: It's up to the specific tagged component, so it is not in any general text. For example, if you had a component that was just an octet, you wouldn't want to force it to be an encapsulation. All component definitions should say that they are (or are not) CDR encapsulations containing . take care, Jon Bill Janssen wrote: > > I can't find any text in the CORBA 2.2 spec which says explicitly > whether the "component_data" field of IOP::TaggedComponent is > actually > an encapsulation, or something else. > > Why don't we define a typedef "Encapsulation" for "sequence", > and use it in the IDL for those octet sequences which are really > encapsulations? > > Bill Return-Path: Date: Mon, 29 Jun 1998 18:04:16 -0400 From: Paul H Kyzivat Organization: NobleNet To: Bill Beckwith CC: interop@omg.org Subject: Re: Issue: marshal type any as an encapsulation References: <199806250338.XAA20699@gamma.ois.com> <35925727.4224AE8E@iona.com> <199806291914.PAA21416@gamma.ois.com> Bill Beckwith wrote: > > At 12:31 PM 6/25/98 , Paul H Kyzivat wrote: > > > >While things may have improved recently, as of a year ago or so I > don't > >think any of the popular ORBs were capable of receiving an Any > >containing a type that wasn't known to them at the time the > receiving > >program was built. If we want to see this fixed we shouldn't be > making > >the job even harder. > > Our ORB, ORBexpress, does support receiving and transmitting anys > that > aren't known at compile time (not very Ada-like, eh ;-). > Encapsulating the any data makes this easier to do this, not harder. > > >It ought to be easy and cheap to receive and retransmit an Any > >regardless of what it might contain. The cost of dealing with an > unknown > >contained type should only be paid in the rare case that it must > be. > > Encapsulating the Any data would eliminate the current need for an > interpretive marshalling since the size and endian of the Any data > would be known a priori to the marshalling routines and all content > knowledge can be delegated to generated code. > > Granted, developing and debugging these dynamic type any marshalling > routines is another barrier of entry into the ORB business, but I > hate > to see performance suffer because of it. :-) No point in trying to argue your case with me - I am on your side! My point about making it harder was poorly worded. It is the existing manner of marshalling Any that makes it hard to marshal an Any that is not known at compile time. I assert that this is one of the reasons why there are so few implementations that do the full job. I should have said that if we want to see Any implemented correctly we should make it easier to do. Marshalling the data of the any in a way that allows it to be taken off the wire without interpretting the typecode is what is needed here. This could be by sending that data as a normal encapsulation, or by doing something else that allows fragmentation without requiring the marshalled size to be computed in advance. Return-Path: Date: Mon, 29 Jun 1998 15:13:08 -0700 From: David.Brownell@Eng.Sun.COM (David Brownell) To: bill.beckwith@ois.com, paulk@noblenet.com Subject: Re: Issue: marshal type any as an encapsulation Cc: interop@omg.org X-Sun-Charset: US-ASCII > My point about making it harder was poorly worded. It is the existing > manner of marshalling Any that makes it hard to marshal an Any that is > not known at compile time. I assert that this is one of the reasons why > there are so few implementations that do the full job. Although the very first implementation of IIOP did that right ... it's all necessary to do DII and DSI correctly. And no, I didn't think it was particularly hard; it's an issue of whether compiled marshaling is the design center, or purely a performance optmization. - Dave Return-Path: Date: Mon, 20 Jul 1998 13:21:56 -0400 From: Bob Kukura Organization: IONA Technologies To: interop@omg.org Subject: interop vote 1 Here are IONA/Martin's votes for vote 1: 782, 885, 935, 1503, 1525, 1544, 1588, 1669, IIOPMessagingRFP, IIOPFirewallRFP: YES 1303: NO - We agree with Jon Biggar that the TAG_ENDPOINT_ID_POSITION, and maybe TAG_LOCATION_POLICY, components should be available for GIOP to use. Even if these components are not sufficient, some other solution for optimization of object location should be adopted. Therefore, we'd rather leave this issue open for the next RTF rather than close it with no action. On 1588, our YES vote is contingent on only the note being added, and not the Encapsulation typedef, since we haven't seen actual text incorporating the typedef into existing component definitions. Our understanding of the IIOPFirewallRFP item is that only chapter 5 of orbos/98-07-03 is being incorporated, and nothing firewall specific. Chapter 5 defines a ServiceContext that is used to negotiate the ability to use the same connection for both client and server roles, and a Policy passed to create_POA() to enable this. Finally, has vote 2 been issued? If so, could someone forward me a copy? Thanks, -Bob