Issue 3097: Custom Value Marshaling Issue (corba-rtf) Source: Camros Corporation (Mr. Jeffrey A. Marshall, jam(at)camros.com) Nature: Uncategorized Issue Severity: Summary: Due to the way that custom values are marshaled it is nearly impossible for a bridge (or other process) to process/forward GIOP messages which contain custom marshaled values (which the bridge has no compile/run-time knowledge of). The main issue is that the "alignment" of the custom marshaled data is unknown, other than the data will always start on a four byte boundry due to the presence of chunking. Should/could the value encoding format be changed to enforce eight byte alignment for all custom marshaled data (chunks)? This would allow bridges and other tools to process->[store]->forward messages containing custom values. Resolution: Deferred to next RTF Revised Text: Actions taken: December 7, 1999: received issue March 7, 2002: moved to Core RTF April 11, 2012: Deferred Discussion: End of Annotations:===== Date: 7 Dec 1999 03:28:01 -0000 Message-ID: <19991207032801.23633.qmail@grub.paragon-software.com> From: "Jeffrey A. Marshall" To: interop@omg.org, issues@omg.org Subject: Custom Value Marshaling Issue Reply-to: jam@camros.com X-Organization: Camros Corporation Content-Type: text X-UIDL: ($i!!%D$!!X5ed9Z8I!! Due to the way that custom values are marshaled it is nearly impossible for a bridge (or other process) to process/forward GIOP messages which contain custom marshaled values (which the bridge has no compile/run-time knowledge of). The main issue is that the "alignment" of the custom marshaled data is unknown, other than the data will always start on a four byte boundry due to the presence of chunking. Should/could the value encoding format be changed to enforce eight byte alignment for all custom marshaled data (chunks)? This would allow bridges and other tools to process->[store]->forward messages containing custom values. -jeff ------------------- Jeffrey A. Marshall Camros Corporation Email jam@camros.com Voice 703-876-1700 ext. 10 Fax 703-876-1818 http://www.camros.com/ Date: Mon, 04 Nov 2002 17:47:55 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Issue 3097 Discussion Any ideas on what to do for this one? Jishnu. ________________________________________________________________ Issue 3097: Custom Value Marshaling Issue (interop) Click here for this issue's archive. Source: Camros Corporation (Mr. Jeffrey A. Marshall, jam@camros.com) Nature: Uncategorized Issue Severity: Summary: Due to the way that custom values are marshaled it is nearly impossible for a bridge (or other process) to process/forward GIOP messages which contain custom marshaled values (which the bridge has no compile/run-time knowledge of). The main issue is that the "alignment" of the custom marshaled data is unknown, other than the data will always start on a four byte boundry due to the presence of chunking. Should/could the value encoding format be changed to enforce eight byte alignment for all custom marshaled data (chunks)? This would allow bridges and other tools to process->[store]->forward messages containing custom values. Sender: jbiggar@Resonate.com Date: Mon, 04 Nov 2002 16:02:39 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Issue 3097 Discussion Jishnu Mukerji wrote: > > Any ideas on what to do for this one? > > Jishnu. > > ________________________________________________________________ > Issue 3097: Custom Value Marshaling Issue (interop) > > Click here for this issue's archive. > Source: Camros Corporation (Mr. Jeffrey A. Marshall, jam@camros.com) > Nature: Uncategorized Issue > Severity: > Summary: > > Due to the way that custom values are marshaled it is nearly impossible > for a bridge (or other process) to process/forward GIOP messages which > contain custom marshaled values (which the bridge has no > compile/run-time knowledge of). > > The main issue is that the "alignment" of the custom marshaled data is > unknown, other than the data will always start on a four byte boundry > due to the presence of chunking. > > Should/could the value encoding format be changed to enforce eight byte > alignment for all custom marshaled data (chunks)? This would allow > bridges and other tools to process->[store]->forward messages > containing custom values. This one is in my list of issues I volunteered to take a stab at. My current thinking the only way to fix this is to change the CDR marshaling format for valuetypes to be more self-contained, which would require a new revision of GIOP/IIOP/CDR. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 05 Nov 2002 10:45:28 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Issue 3097 Discussion I think it might be a good idea to do a "sense of the RTF" vote on that course of action to see if it is likely to fly befre the effort is put into the details. I will put it on the vote that goes out today. Thanks, Jishnu. Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > > Any ideas on what to do for this one? > > > > Jishnu. > > > > ________________________________________________________________ > > Issue 3097: Custom Value Marshaling Issue (interop) > > > > Click here for this issue's archive. > > Source: Camros Corporation (Mr. Jeffrey A. Marshall, jam@camros.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: > > > > Due to the way that custom values are marshaled it is nearly impossible > > for a bridge (or other process) to process/forward GIOP messages which > > contain custom marshaled values (which the bridge has no > > compile/run-time knowledge of). > > > > The main issue is that the "alignment" of the custom marshaled data is > > unknown, other than the data will always start on a four byte boundry > > due to the presence of chunking. > > > > Should/could the value encoding format be changed to enforce eight byte > > alignment for all custom marshaled data (chunks)? This would allow > > bridges and other tools to process->[store]->forward messages > > containing custom values. > > This one is in my list of issues I volunteered to take a stab at. > > My current thinking the only way to fix this is to change the CDR > marshaling format for valuetypes to be more self-contained, which would > require a new revision of GIOP/IIOP/CDR. Sender: jbiggar@Resonate.com Date: Tue, 05 Nov 2002 10:43:57 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Issue 3097 Discussion Jishnu Mukerji wrote: > > I think it might be a good idea to do a "sense of the RTF" vote on that > course of action to see if it is likely to fly befre the effort is put > into the details. I will put it on the vote that goes out today. Ok, this same solution would also address the problem of ensuring that valuetypes embedded in an any can be passed through bridges and services like the Event Service without failure or truncation. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 05 Nov 2002 11:27:42 -0800 From: Ke Jin Subject: Re: Issue 3097 Discussion To: Jonathan Biggar Cc: corba-rtf@omg.org Organization: Borland Software Corp. X-Mailer: Mozilla 4.05 [en] (WinNT; U) Jonathan Biggar wrote: > Jishnu Mukerji wrote: > > > > I think it might be a good idea to do a "sense of the RTF" vote on that > > course of action to see if it is likely to fly befre the effort is put > > into the details. I will put it on the vote that goes out today. > > Ok, this same solution would also address the problem of ensuring that > valuetypes embedded in an any can be passed through bridges and services > like the Event Service without failure or truncation. Passing valuetypes through event/notification, or any other bridge services, should not have problem with the current OMG specification, regardless the valuetype is embedded in a CORBA Any or not. The only restriction, which isn't a problem for real applications, is the filter condition should not refer header fields/parameters locate behind a valuetype field/parameter in structured/typed events. So, I don't see it is necessary to change GIOP for this reason. Regards, Ke > > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Date: Wed, 27 Nov 2002 13:28:53 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: CORBA Core RTF Subject: Discussion of sense of RTF issues so far So far we have voted on 4 sense of RTF issues. Here is a little update on what follows from those: 1. R1: Issues dealing with making ORB available to POA, PIs and Access to ValueFactory from PI. related issues: Issue 3403: PI needs the ORB to be available in IDL (Interceptors) Issue 3772: ORB accessor on POA? Issue 3793: No way to register value factory from ORB initializer (Interceptors) and also 3322. Status: We have been slowly putting together a concrete resolution. It is almost ready to go and should appear in vote 10 or 11. 2. R2 Regarding how to resolve issue 2772 Related Issue 2772 Status: It looks like the general feeling was that 2772 should be fixed as suggested in R2. We are awaiting a concrete draft resolution from Jon Biggar. As soon as it is available we will put it to vote. 3. R3: On the matter of how to resolve Issue 3097. Status: There is considerable reluctance on part of the voters to create a new version of GIOP to solve this problem, even though R3 did pass by a thin margin. But the fact that No's + Abstains outnumber Yesses by a significant margin should give us significant pause before we proceed down the path proposed in R3. We need to decide how to handle this one. Choices are leave it open (least desirable) or close with documentation of the problem in the specification. 4. R4: On the matter of how to resolve Issue 4169. Status: This one passed decisively. Jon had some objections that can probably be mitigated with some thought. It is upto Harold to come up with a complete draft resolution for this, in consultation with Jon. As soon as the draft is available we will put it to vote. Date: Mon, 02 Dec 2002 14:14:39 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Issue 3097 Discussion Jonathan Biggar wrote: > > This one is in my list of issues I volunteered to take a stab at. > > My current thinking the only way to fix this is to change the CDR > marshaling format for valuetypes to be more self-contained, which > would > require a new revision of GIOP/IIOP/CDR. Jon, the sense that I get from the vote on R3 (5Y, 4N, 4A, 1NV) is that this approach has a very slim chance of being accepted, since it will not take much for one or more of the abstainees to change to a NO vote. The only option that that leaves us with at this point is to try to provide a less than optimum resoltuion that does not involve a GIOP/IIOP/CDR version change, or to just leave it open. Considering that this has been open since 1999, and no one seems to be particularly bothered about it, siggest to me that we should probably insert a note in the specification about this problem (like do not use custom value marshaling if you expect it to go through a bridge) and leave it at that. What do you suggest we do about this? Jishnu. Sender: jon@floorboard.com Date: Wed, 11 Dec 2002 20:43:13 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Issue 3097 Discussion Jishnu Mukerji wrote: > > This one is in my list of issues I volunteered to take a stab at. > > > > My current thinking the only way to fix this is to change the CDR > > marshaling format for valuetypes to be more self-contained, which would > > require a new revision of GIOP/IIOP/CDR. > > Jon, > > the sense that I get from the vote on R3 (5Y, 4N, 4A, 1NV) is that this > approach has a very slim chance of being accepted, since it will not > take much for one or more of the abstainees to change to a NO vote. The > only option that that leaves us with at this point is to try to provide > a less than optimum resoltuion that does not involve a GIOP/IIOP/CDR > version change, or to just leave it open. Considering that this has been > open since 1999, and no one seems to be particularly bothered about it, > siggest to me that we should probably insert a note in the specification > about this problem (like do not use custom value marshaling if you > expect it to go through a bridge) and leave it at that. > > What do you suggest we do about this? Actually, my read on the voting is that people think it's a good idea in general, but are reluctant to bump GIOP a rev just for that change. I have sympathy for that sentiment. Would it be possible to work up the solution and issue it as a separate report with instructions to hold integrating it into the standard until the next big GIOP change is rolled in too? I think that would be the Firewall spec. Does anybody else object to that approach to avoid version whiplash? A couple of people also commented that they'd like to see a more general versioning solution added to GIOP, but I don't see how that is workable without adding a whole lot of extra overhead to the protocol. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 11 Dec 2002 23:14:42 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 3097 Discussion To: jishnu@hp.com, jon@floorboard.com Cc: corba-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >From: Jonathan Biggar >X-Accept-Language: en >MIME-Version: 1.0 >To: Jishnu Mukerji >CC: corba-rtf@omg.org >Subject: Re: Issue 3097 Discussion >Content-Transfer-Encoding: 7bit > >Jishnu Mukerji wrote: >> > This one is in my list of issues I volunteered to take a stab at. >> > >> > My current thinking the only way to fix this is to change the CDR >> > marshaling format for valuetypes to be more self-contained, which >would >> > require a new revision of GIOP/IIOP/CDR. >> >> Jon, >> >> the sense that I get from the vote on R3 (5Y, 4N, 4A, 1NV) is that >this >> approach has a very slim chance of being accepted, since it will >not >> take much for one or more of the abstainees to change to a NO >vote. The >> only option that that leaves us with at this point is to try to >provide >> a less than optimum resoltuion that does not involve a >GIOP/IIOP/CDR >> version change, or to just leave it open. Considering that this has >been >> open since 1999, and no one seems to be particularly bothered about >it, >> siggest to me that we should probably insert a note in the >specification >> about this problem (like do not use custom value marshaling if you >> expect it to go through a bridge) and leave it at that. >> >> What do you suggest we do about this? > >Actually, my read on the voting is that people think it's a good idea >in >general, but are reluctant to bump GIOP a rev just for that change. >I >have sympathy for that sentiment. > >Would it be possible to work up the solution and issue it as a >separate >report with instructions to hold integrating it into the standard >until >the next big GIOP change is rolled in too? I think that would be the >Firewall spec. > >Does anybody else object to that approach to avoid version whiplash? > This approach is fine with me. >A couple of people also commented that they'd like to see a more general >versioning solution added to GIOP, but I don't see how that is workable >without adding a whole lot of extra overhead to the protocol. > I'm not sure that it's a lot of overhead, but it could easily lead to overly complex interoperability profiles, and I really do not want to see that happen. Ken. Date: Thu, 12 Dec 2002 12:34:34 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Issue 3097 Discussion Jonathan Biggar wrote: > > Actually, my read on the voting is that people think it's a good idea in > general, but are reluctant to bump GIOP a rev just for that change. I > have sympathy for that sentiment. > > Would it be possible to work up the solution and issue it as a separate > report with instructions to hold integrating it into the standard until > the next big GIOP change is rolled in too? I think that would be the > Firewall spec. > > Does anybody else object to that approach to avoid version whiplash? Sounds good to me. Firewall FTF, which BTW has pretty much been sitting on its thumbs and has done nothing so far:-( has a report due date of June 9, which is presumably targeted for the Paris meeting. We could simply plan on doing a report targeted for the Paris meeting, and include a resolution to this issue (with wording that says that it is to be incorporated in conjunction with the output from the Firewall FTF and the associated new GIOP version), and whatever else happens to get resolved. You can start working on a resolution, but let us not vote on it in this RTF cycle, just to help me and a few others maintain their sanity.:-) > A couple of people also commented that they'd like to see a more general > versioning solution added to GIOP, but I don't see how that is workable > without adding a whole lot of extra overhead to the protocol. It would be worthwile creating an issue for this and use that as a discussion point and again the realistic target for doing anything of the sort has to be aligned with the June Paris meeting. Jishnu.