Issue 3601: Portable Interceptors: 9.2.3 text describing `Arguments' (corba-rtf) Source: DSTC (Mr. Ted McFadden, mcfadden(at)dstc.edu.au) Nature: Uncategorized Issue Severity: Minor Summary: The text in section 9.2.3 / page 9-71 describing the arguments attribute to ORBInitInfo could use some more precise wording. It reads: "This attribute contains the arguments passed to ORB_init. They may or may not contain the ORB's arguments." I take this to mean that any ORB_init arguments that applied to the ORB instance being created may not be present. All other strings passed to ORB_init will be present so initialisation strings can be passed to the interceptors through ORB_init. With the current text it is possible to think that you may not get *any* of the arguments to ORB_init. Resolution: see above Revised Text: Actions taken: May 3, 2000: received issue April 28, 2003: closed issue Discussion: Resolution: Issue 5690 addresses this in a more specific focused way. So close this issue and merge its discussion into 5690. End of Annotations:===== Date: Wed, 3 May 2000 16:22:13 +1000 From: Ted McFadden To: issues@omg.org Subject: Portable Interceptors: 9.2.3 text describing `Arguments' Message-ID: <20000503162213.C18056@ooc.com.au> Mail-Followup-To: issues@omg.org Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: b1Ie9j[)e9T/^!!Xncd9 A minor issue: The text in section 9.2.3 / page 9-71 describing the arguments attribute to ORBInitInfo could use some more precise wording. It reads: "This attribute contains the arguments passed to ORB_init. They may or may not contain the ORB's arguments." I take this to mean that any ORB_init arguments that applied to the ORB instance being created may not be present. All other strings passed to ORB_init will be present so initialisation strings can be passed to the interceptors through ORB_init. With the current text it is possible to think that you may not get *any* of the arguments to ORB_init. Cheers, Ted -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4 904 Stanley St. +61-7-3891-5744 East Brisbane 4169, QLD. Australia From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA37398 for ; Mon, 22 May 2000 10:01:17 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id KAA36030 for ; Mon, 22 May 2000 10:13:45 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E7.004E294B ; Mon, 22 May 2000 10:13:43 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568E7.004DDF89.00@d54mta04.raleigh.ibm.com> Date: Mon, 22 May 2000 10:10:33 -0400 Subject: Issue 3601 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id KAA09436 Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 1H4!!Q(@!!$;Xd9C$Pe9 The following paragraph from doc # ptc/2000-04-05, page 21-42, is unclear: 21.7.2.3 arguments This attribute contains the arguments passed to ORB_init. They may or may not contain the ORB?s arguments. I propose to replace it with the following: 21.7.2.3 arguments This attribute contains the arguments passed to ORB_init. It may or may not contain the arguments which the ORB recognizes. It shall contain all arguments passed to ORB_init which the ORB does not recognize. Russell Butek butek@us.ibm.com Reply-To: From: "Nick Sharman" To: , Subject: RE: Issue 3601 proposal Date: Mon, 22 May 2000 16:02:19 +0100 Message-ID: <005301bfc3fe$b9e70da0$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <852568E7.004DDF89.00@d54mta04.raleigh.ibm.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: $Cg!!Heb!!>Y@e9EVhd9 Russell, Here's a counter-proposal: I propose to replace it with the following: 21.7.2.3 arguments This attribute contains the arguments passed to ORB_init. It *shall not* contain the arguments which the ORB recognizes. It shall contain all arguments passed to ORB_init which the ORB does not recognize. This is similar to the way the C/C++ ORB_init implementations are supposed to strip out the ORB's stuff before returning to the application. Suppose an interceptor is passed two strings "-ORBmyparam" "somevalue", has the ORB eaten "somevalue" as the value of "-ORBmyparam", or might it have recognized its "-ORBmy" parameter with value "param" as one string, leaving "somevalue" for the interceptor to examine? (and should the interceptors somehow strip _their_ parameters before they return to the ORB, so that they too are invisible to the app?) Regards Nick > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Monday, May 22, 2000 3:11 PM > To: interceptors-ftf@omg.org > Subject: Issue 3601 proposal > > > > > The following paragraph from doc # ptc/2000-04-05, page 21-42, is unclear: > > 21.7.2.3 arguments > > This attribute contains the arguments passed to ORB_init. They may or > may not > contain the ORB?s arguments. > > I propose to replace it with the following: > > 21.7.2.3 arguments > > This attribute contains the arguments passed to ORB_init. It may or > may not > contain the arguments which the ORB recognizes. It shall contain all > arguments passed to ORB_init which the ORB does not recognize. > > > Russell Butek > butek@us.ibm.com > > > From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA33786 for ; Mon, 22 May 2000 12:58:52 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id NAA56504 for ; Mon, 22 May 2000 13:11:20 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E7.005E6A88 ; Mon, 22 May 2000 13:11:16 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568E7.005D90CB.00@d54mta04.raleigh.ibm.com> Date: Mon, 22 May 2000 13:01:57 -0400 Subject: RE: Issue 3601 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: "pCe9GRS!!%F1!!lA*e9 "Nick Sharman" on 05/22/2000 10:02:19 AM > > Russell, > > Here's a counter-proposal: > > I propose to replace it with the following: > > 21.7.2.3 arguments > > This attribute contains the arguments passed to ORB_init. It *shall > not* > contain the arguments which the ORB recognizes. It shall contain all > arguments passed to ORB_init which the ORB does not recognize. > > This is similar to the way the C/C++ ORB_init implementations are supposed > to strip out the ORB's stuff before returning to the application. This is similar, yes, but C/C++ ORB_init is only required to strip the ORB arguments before returning control to the application. It could do that before or after calling the ORB initializers. The reason the C++ mapping says to strip these is for convenience - the application doesn't have to parse arguments that it knows nothing about. But ORB initializers, and interceptors particularly, are really ORB-level code. Perhaps having access to the ORB parameters would be useful. I personally don't understand why we should say the ORB parameters "may or may not" be there, but that's what the spec says, and this issue simply asked for a clarification. If we really were going to change the meaning of this paragraph, I'd prefer to do it in the opposite direction than you suggest: "This attribute shall contain all the arguments that are passed to ORB_init." > > Suppose an interceptor is passed two strings "-ORBmyparam" >"somevalue", has > the ORB eaten "somevalue" as the value of "-ORBmyparam", or might it >have > recognized its "-ORBmy" parameter with value "param" as one string, leaving > "somevalue" for the interceptor to examine? I don't understand what you're asking. If the ORB strips off its parameters, then it does them appropriately and there's no confusion. If the ORB does not strip off its parameters, then it's very unfortunate if "somevalue" happens to be a value for the ORB and a parameter for an ORB initializer. The initializer should define better parameters - like something beginning with "-" - that shouldn't be a value to the ORB. > > (and should the interceptors somehow strip _their_ parameters before >they > return to the ORB, so that they too are invisible to the app?) This would be impossible in Java (well, nothing's impossible, but it would be a chore that would probably require a major deviation in the existing ORB.init interfaces). > So, in short, I suggest we don't change the meaning of that paragraph (unless everyone thinks we should, of course) since the issue is only asking for a clarification. Russell Butek butek@us.ibm.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3601 proposal Date: Mon, 22 May 2000 15:47:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: =\nd9@'dd9Vo8!!MU_d9 > From: Nick Sharman [mailto:nick.sharman@peerlogic.com] > (and should the interceptors somehow strip _their_ > parameters before they > return to the ORB, so that they too are invisible to the app?) Nick, this is a good catch. And it introduces some other issues to be considered: - can interceptors have arguments of their own? - if so, how are they recognized? My feeling is that interceptors are used to extend the orb. A user is likely not to know what features come as a result of an interceptor and what ones are built into the orb. As a result, orbinit arguments should be named for the feature they support, not the interceptor that happens to implement that feature. But this makes it difficult to assign responsibility for parsing the relevant arguments from the original argument list. It could be the responsibility of the ORB to process all the arguments that it understands, and make them available to interceptors. But in that case, the interceptors are dependent on the orb to understand their arguments. An alternative is to permit the interceptors to see all the arguments and claim the ones they want. But this could lead to conflicts. Suppose one interceptor things there should be an argument -ORBfoo that has no value, and another wants -ORBfoo with a value. I suppose each interceptor could register the arguments it requirements, with the number of values that should go with it. But that doesn't sound very appealing. Or, maybe interceptors simply can't be dependent on arguments. Paul Date: Tue, 23 May 2000 07:01:06 +1000 (EST) From: Michi Henning To: Nick Sharman cc: butek@us.ibm.com, interceptors-ftf@omg.org Subject: RE: Issue 3601 proposal In-Reply-To: <005301bfc3fe$b9e70da0$5610a8c0@thumper.uk.peerlogic.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2P9e9@TWd9%"#e9G?Ce9 On Mon, 22 May 2000, Nick Sharman wrote: > Suppose an interceptor is passed two strings "-ORBmyparam" "somevalue", has > the ORB eaten "somevalue" as the value of "-ORBmyparam", or might it have > recognized its "-ORBmy" parameter with value "param" as one string, leaving > "somevalue" for the interceptor to examine? I think that one is a red herring. If I make ORB options that are open to misinterpretation in this way, I get what I deserve. Besides, for multi-character options, the option argument should never be placed without a whitespace separator, so I think the point is moot -- it would always be interpreted as "-ORBmyparam". 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 Reply-To: From: "Nick Sharman" To: Subject: RE: Issue 3601 proposal Date: Tue, 23 May 2000 08:14:13 +0100 Message-ID: <006001bfc486$7f9b5010$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Q[7e9_'-!!EH\d9DiI!! > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Monday, May 22, 2000 10:01 PM > > On Mon, 22 May 2000, Nick Sharman wrote: > > > Suppose an interceptor is passed two strings "-ORBmyparam" > "somevalue", has > > the ORB eaten "somevalue" as the value of "-ORBmyparam", or > might it have > > recognized its "-ORBmy" parameter with value "param" as one > string, leaving > > "somevalue" for the interceptor to examine? > > I think that one is a red herring. If I make ORB options that are open to > misinterpretation in this way, I get what I deserve. Besides, > for multi-character options, the option argument should never be placed > without a whitespace separator, so I think the point is moot -- it > would always be interpreted as "-ORBmyparam". > Would that it were so. From sec. 4.5.1 of ptc/00-03-02 (unchanged from CORBA 2.3.1): Other parameters of significance to the ORB can also be identified in arg_list, for example , and so forth. To allow for other parameters to be specified without causing applications to be re-written, it is necessary to specify the parameter format that ORB parameters may take. In general, parameters shall be formatted as either one single arg_list parameter: -ORB ^^^^^^^^ or as two sequential arg_list parameters: -ORB Preceding text describing -ORBid also gives an example with no embedded space. Regards Nick Reply-To: From: "Nick Sharman" To: Subject: RE: Issue 3601 proposal Date: Tue, 23 May 2000 08:34:19 +0100 Message-ID: <006101bfc489$4e491800$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <852568E7.005D90CB.00@d54mta04.raleigh.ibm.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 7JP!!f&?e9UJV!!+&G!! > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Monday, May 22, 2000 6:02 PM > > "Nick Sharman" on 05/22/2000 10:02:19 AM > > > > Russell, > > > > Here's a counter-proposal: > > > > I propose to replace it with the following: > > > > 21.7.2.3 arguments > > > > This attribute contains the arguments passed to ORB_init. It *shall > > not* > > contain the arguments which the ORB recognizes. It shall > contain all > > arguments passed to ORB_init which the ORB does not recognize. > > > > This is similar to the way the C/C++ ORB_init implementations are > supposed > > to strip out the ORB's stuff before returning to the application. > > This is similar, yes, but C/C++ ORB_init is only required to strip the ORB > arguments before returning control to the application. It could do that > before or after calling the ORB initializers. > > The reason the C++ mapping says to strip these is for convenience - the > application doesn't have to parse arguments that it knows nothing about. > But ORB initializers, and interceptors particularly, are really ORB-level > code. Agreed, but one of the purposes of portable interceptors is so that vendor A's OTS can run inside any vendors ORB. Having to understand the ORB parameters supported by vendor B's ORB and vendor C's ORB and ... works against this, just as it does for the portable application (or object service) developer. > Perhaps having access to the ORB parameters would be useful. I > personally don't understand why we should say the ORB parameters > "may or > may not" be there, but that's what the spec says, and this issue > simply > asked for a clarification. If we really were going to change the > meaning > of this paragraph, I'd prefer to do it in the opposite direction > than you > suggest: > > "This attribute shall contain all the arguments that are passed to > ORB_init." > > > > > Suppose an interceptor is passed two strings "-ORBmyparam" > "somevalue", > has > > the ORB eaten "somevalue" as the value of "-ORBmyparam", or > might it have > > recognized its "-ORBmy" parameter with value "param" as one > string, > leaving > > "somevalue" for the interceptor to examine? > > I don't understand what you're asking. If the ORB strips off its > parameters, then it does them appropriately and there's no > confusion. If > the ORB does not strip off its parameters, then it's very > unfortunate if > "somevalue" happens to be a value for the ORB and a parameter for an > ORB > initializer. The initializer should define better parameters - like > something beginning with "-" - that shouldn't be a value to the ORB. > > > > > (and should the interceptors somehow strip _their_ parameters > before they > > return to the ORB, so that they too are invisible to the app?) > > This would be impossible in Java (well, nothing's impossible, but it > would > be a chore that would probably require a major deviation in the > existing > ORB.init interfaces). > I suspect that here, as in its lack of orbid parameter, the Java > mapping fails to live up to the CORBA spec (from ptc/00-03-02, sec. 4.5.1): Before ORB_init returns, it will remove from the arg_list parameter all strings that match the -ORB pattern described above and that are recognized by that ORB implementation, along with any associated sequential parameter strings. If any strings in arg_list that match this pattern are not recognized by the ORB implementation, ORB_init will raise the BAD_PARAM system exception instead. (I think this section also implies that interceptor parameters shouldn't start with "-ORB", otherwise the ORB is likely to object to them. Is that correct?) Regards Nick Reply-To: From: "Nick Sharman" To: Subject: RE: Issue 3601 proposal Date: Tue, 23 May 2000 08:34:22 +0100 Message-ID: <006201bfc489$4ffc9460$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BEB0@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: c!'e9(kH!!MWid9i+Ne9 > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: Monday, May 22, 2000 8:47 PM > To: interceptors-ftf@omg.org > Subject: RE: Issue 3601 proposal > > > > From: Nick Sharman [mailto:nick.sharman@peerlogic.com] > > > (and should the interceptors somehow strip _their_ > > parameters before they > > return to the ORB, so that they too are invisible to the app?) > > Nick, this is a good catch. And it introduces some other issues to be > considered: > > - can interceptors have arguments of their own? > - if so, how are they recognized? > > My feeling is that interceptors are used to extend the orb. > A user is likely not to know what features come as a result of an > interceptor and what ones are built into the orb. > Perhaps, but most ORB::init args are vendor specific, so a user will need to read their supplier's manuals before knowing what parameters can be supplied. That would allow them to guess in most cases, unless an ORB vendor uses PIs as an implementation convenience for some 'bundled' capabilities. > As a result, orbinit arguments should be named for the feature > they support, > not the interceptor that happens to implement that feature. > > But this makes it difficult to assign responsibility for parsing the > relevant arguments from the original argument list. It could be the > responsibility of the ORB to process all the arguments that it > understands, > and make them available to interceptors. But in that case, the > interceptors > are dependent on the orb to understand their arguments. > > An alternative is to permit the interceptors to see all the > arguments and > claim the ones they want. But this could lead to conflicts. Suppose > one > interceptor things there should be an argument -ORBfoo that has no > value, > and another wants -ORBfoo with a value. > We have some ORB parameters that don't take a value (presence or > absence is enough), however I'm not sure whether that's really legal CORBA. > Anyone else care to comment. > I suppose each interceptor could register the arguments it requirements, > with the number of values that should go with it. > But that doesn't sound very appealing. > Agreed. > Or, maybe interceptors simply can't be dependent on arguments. > Well, that would cut the Gordian knot, but I'm not sure it's >practical, any more than for the ORB itself. > Paul > Regards Nick Date: Tue, 23 May 2000 18:11:28 +1000 (EST) From: Michi Henning To: Nick Sharman cc: interceptors-ftf@omg.org Subject: RE: Issue 3601 proposal In-Reply-To: <006001bfc486$7f9b5010$5610a8c0@thumper.uk.peerlogic.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by emerald.omg.org id EAA17384 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-UIDL: 'Kh!!'T>e9%Gg!!Ok>!! On Tue, 23 May 2000, Nick Sharman wrote: > > I think that one is a red herring. If I make ORB options that are open to > > misinterpretation in this way, I get what I deserve. Besides, > > for multi-character options, the option argument should never be placed > > without a whitespace separator, so I think the point is moot -- it > > would always be interpreted as "-ORBmyparam". > > > Would that it were so. From sec. 4.5.1 of ptc/00-03-02 (unchanged from > CORBA 2.3.1): > > Other parameters of significance to the ORB can also be identified in > arg_list, for example , and so forth. To > allow for other parameters to be specified without causing applications > to be re-written, it is necessary to specify the parameter format that > ORB parameters may take. In general, parameters shall be formatted as > either one single arg_list parameter: > > -ORB > ^^^^^^^^ > > or as two sequential arg_list parameters: > > -ORB > > > Preceding text describing -ORBid also gives an example with no embedded > space. OK. But then, if you permit, for example -ORBidfoo and -ORBid foo, then there cannot any other option that starts with "-ORBid" but is longer, such as "-ORBidxxx", because then I couldn't distinguish between -ORBid and -ORBidxxx anymore. 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: interceptors-ftf@omg.org Subject: RE: Issue 3601 proposal Date: Tue, 23 May 2000 08:47:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: OEXd92SRd9i?Ke9M=/!! It seems to me we have dug ourselves a hole with the notion of orb services that are independent of the orb and coupled only via portable interceptors. The problem is that we don't have a corresponding way to decouple ORBinit parameters. On the one hand, we probably want them all to have a common prefix (-ORB) to provide some sanity for users, and some ability for the orb to diagnose the presence of invalid parameters. On the other hand, separately provisioned orb services most likely need the ability to define their own parameter requirements, without requiring the ORB to be aware of those requirements a priori. About the only thing I can see that satisfies those conflicting needs is an api on the orb initializer to query for the presence of particular argument keys, together with the associated value syntax. (E.g., Just key w/ no value; one value; N values.) This would permit the orb to process the arguments, identify those tagged for the ORB, figure out which values to extract with them, and identify orb arguments that were unexpected. We have something a little like this in our orb, but quite a bit more restricted. Paul > -----Original Message----- > From: Nick Sharman [mailto:nick.sharman@peerlogic.com] > Sent: Tuesday, May 23, 2000 3:34 AM > To: interceptors-ftf@omg.org > Subject: RE: Issue 3601 proposal > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > Sent: Monday, May 22, 2000 8:47 PM > > To: interceptors-ftf@omg.org > > Subject: RE: Issue 3601 proposal > > > > > > > From: Nick Sharman [mailto:nick.sharman@peerlogic.com] > > > > > (and should the interceptors somehow strip _their_ > > > parameters before they > > > return to the ORB, so that they too are invisible to the app?) > > > > Nick, this is a good catch. And it introduces some other > issues to be > > considered: > > > > - can interceptors have arguments of their own? > > - if so, how are they recognized? > > > > My feeling is that interceptors are used to extend the orb. > > A user is likely not to know what features come as a result of an > > interceptor and what ones are built into the orb. > > > Perhaps, but most ORB::init args are vendor specific, so a > user will need to > read their supplier's manuals before knowing what parameters can be > supplied. That would allow them to guess in most cases, > unless an ORB vendor > uses PIs as an implementation convenience for some 'bundled' > capabilities. > > > As a result, orbinit arguments should be named for the feature > > they support, > > not the interceptor that happens to implement that feature. > > > > But this makes it difficult to assign responsibility for parsing the > > relevant arguments from the original argument list. It could be the > > responsibility of the ORB to process all the arguments that it > > understands, > > and make them available to interceptors. But in that case, the > > interceptors > > are dependent on the orb to understand their arguments. > > > > An alternative is to permit the interceptors to see all the > arguments and > > claim the ones they want. But this could lead to conflicts. > Suppose one > > interceptor things there should be an argument -ORBfoo that > has no value, > > and another wants -ORBfoo with a value. > > > We have some ORB parameters that don't take a value (presence > or absence is > enough), however I'm not sure whether that's really legal > CORBA. Anyone > else care to comment. > > > I suppose each interceptor could register the arguments it > requirements, > > with the number of values that should go with it. > > But that doesn't sound very appealing. > > > Agreed. > > > Or, maybe interceptors simply can't be dependent on arguments. > > > Well, that would cut the Gordian knot, but I'm not sure it's > practical, any > more than for the ORB itself. > > > Paul > > > Regards > Nick > From: Paul Kyzivat To: "'nick.sharman@peerlogic.com'" , interceptors-ftf@omg.org Subject: RE: Issue 3601 proposal Date: Tue, 23 May 2000 08:47:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: B`Ee9:IP!!Pffd9>BAe9 > From: Nick Sharman [mailto:nick.sharman@peerlogic.com] > (I think this section also implies that interceptor > parameters shouldn't > start with "-ORB", otherwise the ORB is likely to object to > them. Is that correct?) When the section was written, there was no well formed notion of portable interceptors, and hence no notion that such things might want parameters. So I don't think you can draw that conclusion from the text. Using a prefix other than -ORB would be a burden on users. They then have an open ended set of possible prefixes to avoid when passing arguments to their own program. Paul From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3601 proposal Date: Tue, 23 May 2000 08:52:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: eJWd9n%Xd9eF!e9c`V!! > From: Michi Henning [mailto:michi@ooc.com.au] > OK. But then, if you permit, for example -ORBidfoo and -ORBid foo, then > there cannot any other option that starts with "-ORBid" but is longer, > such as "-ORBidxxx", because then I couldn't distinguish between > -ORBid and -ORBidxxx anymore. This is an implication of the spec as it is written. I would certainly be happy to see it changed. Note that currently the following are all valid and equivalent: "-ORBid" "foo" "-ORBidfoo" "-ORBid foo" "-ORBid foo" This hasn't been a huge problem as long as all the parameters were specific to a single orb. But it is going to be much more of a problem as orb-independent orb services start looking for parameters. Paul From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA38762 for ; Tue, 23 May 2000 08:41:26 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id IAA44574 for ; Tue, 23 May 2000 08:53:54 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E8.0046D87B ; Tue, 23 May 2000 08:53:49 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568E8.0046D6DA.00@d54mta04.raleigh.ibm.com> Date: Tue, 23 May 2000 08:53:41 -0400 Subject: RE: Issue 3601 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: p3\!!X%O!!b+\d9k]dd9 "Nick Sharman" on 05/23/2000 02:34:19 AM > > > -----Original Message----- > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > Sent: Monday, May 22, 2000 6:02 PM > > > > "Nick Sharman" on 05/22/2000 10:02:19 AM > > > > > > Russell, > > > > > > Here's a counter-proposal: > > > > > > I propose to replace it with the following: > > > > > > 21.7.2.3 arguments > > > > > > This attribute contains the arguments passed to ORB_init. It *shall > > > not* > > > contain the arguments which the ORB recognizes. It shall > > contain all > > > arguments passed to ORB_init which the ORB does not recognize. > > > > > > This is similar to the way the C/C++ ORB_init implementations are > > supposed > > > to strip out the ORB's stuff before returning to the application. > > > > This is similar, yes, but C/C++ ORB_init is only required to strip the ORB > > arguments before returning control to the application. It could do that > > before or after calling the ORB initializers. > > > > The reason the C++ mapping says to strip these is for convenience - the > > application doesn't have to parse arguments that it knows nothing about. > > But ORB initializers, and interceptors particularly, are really ORB-level > > code. > > Agreed, but one of the purposes of portable interceptors is so that vendor > A's OTS can run inside any vendors ORB. Having to understand the ORB > parameters supported by vendor B's ORB and vendor C's ORB and ... works > against this, just as it does for the portable application (or object > service) developer. I look at this not as a way to look at vendor-specific parameters, but as a way by which to have access to future defined standard ORB parameters without having to change the interceptor API. Right now ORB ID is the only defined parameter (and Java has a couple others) and that's available via ORBInitInfo.orb_id (); What happens when someone decides that -ORBBootstrapHost should be standard? Without having access to the parameters, we'd have to change the ORBInitInfo interface so it can access every such additional parameter. > > > Perhaps having access to the ORB parameters would be useful. I > > personally don't understand why we should say the ORB parameters "may or > > may not" be there, but that's what the spec says, and this issue simply > > asked for a clarification. If we really were going to change the meaning > > of this paragraph, I'd prefer to do it in the opposite direction than you > > suggest: > > > > "This attribute shall contain all the arguments that are passed to > > ORB_init." > > > > > > > > Suppose an interceptor is passed two strings "-ORBmyparam" "somevalue", > > has > > > the ORB eaten "somevalue" as the value of "-ORBmyparam", or > > might it have > > > recognized its "-ORBmy" parameter with value "param" as one string, > > leaving > > > "somevalue" for the interceptor to examine? > > > > I don't understand what you're asking. If the ORB strips off its > > parameters, then it does them appropriately and there's no confusion. If > > the ORB does not strip off its parameters, then it's very unfortunate if > > "somevalue" happens to be a value for the ORB and a parameter for an ORB > > initializer. The initializer should define better parameters - like > > something beginning with "-" - that shouldn't be a value to the ORB. > > > > > > > > (and should the interceptors somehow strip _their_ parameters > > before they > > > return to the ORB, so that they too are invisible to the app?) > > > > This would be impossible in Java (well, nothing's impossible, but it would > > be a chore that would probably require a major deviation in the existing > > ORB.init interfaces). > > > I suspect that here, as in its lack of orbid parameter, the Java mapping > fails to live up to the CORBA spec (from ptc/00-03-02, sec. 4.5.1): > > Before ORB_init returns, it will remove from the arg_list parameter > all strings that match the -ORB pattern described above and > that are recognized by that ORB implementation, along with any > associated sequential parameter strings. If any strings in arg_list > that match this pattern are not recognized by the ORB implementation, > ORB_init will raise the BAD_PARAM system exception instead. Ah. I thought this was a C/C++-only thing. Thanks for pointing it out. However, I wouldn't complain about the Java mapping in this case. I'd complain that the spec was written too closely to C++. There are a number of languages where an arg_list argument cannot be modified by the called method. The spec chooses to ignore these languages, so the mappings have no choice but to deviate. > > (I think this section also implies that interceptor parameters >shouldn't > start with "-ORB", otherwise the ORB is likely to object to them. >Is that > correct?) I agree, but this is another issue. Would you (or anyone) care to open it and propose a resolution? I still think we should just clarify the paragraph as the issue requests, and not change the meaning of the paragraph. I'd like to get the thoughts from other folks, other than just you and I though. Russell Butek butek@us.ibm.com Reply-To: From: "Nick Sharman" To: Subject: RE: Issue 3601 proposal Date: Tue, 23 May 2000 14:15:14 +0100 Message-ID: <006901bfc4b8$ee95bb40$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BEB5@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Al>e97j&!!/V"e9$98e9 > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: Tuesday, May 23, 2000 1:47 PM > To: 'nick.sharman@peerlogic.com'; interceptors-ftf@omg.org > Subject: RE: Issue 3601 proposal > > > > From: Nick Sharman [mailto:nick.sharman@peerlogic.com] > > > (I think this section also implies that interceptor > > parameters shouldn't > > start with "-ORB", otherwise the ORB is likely to object to > > them. Is that correct?) > > When the section was written, there was no well formed notion of portable > interceptors, and hence no notion that such things might want parameters. > So I don't think you can draw that conclusion from the text. > I suspected as much :-( > Using a prefix other than -ORB would be a burden on users. > They then have an open ended set of possible prefixes to avoid > when passing arguments to their own program. > > Paul > I think I agree. Nick From: Jeffrey Mischkinsky Message-Id: <200005231402.HAA21170@wheel.dcn.davis.ca.us> Subject: Re: Issue 3601 proposal To: paulk@roguewave.com (Paul Kyzivat) Date: Tue, 23 May 2000 07:02:52 -0700 (PDT) Cc: nick.sharman@peerlogic.com ('nick.sharman@peerlogic.com'), interceptors-ftf@omg.org In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BEB5@bos1.noblenet.com> from "Paul Kyzivat" at May 23, 2000 08:47:10 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: MBW!!4^-e9Z$ad9QP+!! 'Paul Kyzivat' writes: > > > From: Nick Sharman [mailto:nick.sharman@peerlogic.com] > > > (I think this section also implies that interceptor > > parameters shouldn't > > start with "-ORB", otherwise the ORB is likely to object to > > them. Is that correct?) > > When the section was written, there was no well formed notion of portable > interceptors, and hence no notion that such things might want parameters. > So I don't think you can draw that conclusion from the text. Portable interceptors is another step in the road to regularizing things that were previously the province of how vendors chose to implement particular functions. I like Paul's suggestion of defining an api for how access to initialization pararmeters is made available to orb code, interceptors, services, app code, etc. This reduces the problem to how to specify (syntax in effect) the params which will be (partially) determined by the OS-programming language/program interface conventions. Remember the notions of how params get passed into a program came from the unix/c convention of argc, argv. These kind of things tend to be very specific to OS and language conventions. How's it done in COBOL on a mainframe? > > Using a prefix other than -ORB would be a burden on users. > They then have an open ended set of possible prefixes to avoid > when passing arguments to their own program. I agree. cheers, jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Wed, 24 May 2000 08:06:25 +1000 (EST) From: Michi Henning To: butek@us.ibm.com cc: interceptors-ftf@omg.org Subject: RE: Issue 3601 proposal In-Reply-To: <852568E8.0046D6DA.00@d54mta04.raleigh.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: K09e9MF1e9Q"m!!SY[!! On Tue, 23 May 2000 butek@us.ibm.com wrote: > > I suspect that here, as in its lack of orbid parameter, the Java mapping > > fails to live up to the CORBA spec (from ptc/00-03-02, sec. 4.5.1): > > > > Before ORB_init returns, it will remove from the arg_list parameter > > all strings that match the -ORB pattern described above and > > that are recognized by that ORB implementation, along with any > > associated sequential parameter strings. If any strings in arg_list > > that match this pattern are not recognized by the ORB implementation, > > ORB_init will raise the BAD_PARAM system exception instead. > > > Ah. I thought this was a C/C++-only thing. Thanks for pointing it out. > However, I wouldn't complain about the Java mapping in this case. I'd > complain that the spec was written too closely to C++. There are a number > of languages where an arg_list argument cannot be modified by the called > method. The spec chooses to ignore these languages, so the mappings have > no choice but to deviate. Huh? That's not right, I think. This is purely a mapping issue. If you can't modify argc/argv directly in Java, then the language mapping must take care to pass something to ORB_init() that can be modified, that's all. The Java mapping has stomped on things here in more than one way. For example, the arguments are mapped to a property set, so any ordering that was present for the arguments on the command-line (and that ordering may be significant) is thrown away. That's simply an incorrect mapping given that the arguments are sequence, not a set. It would be nice to fix the Java mapping, really... 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: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA40994 for ; Wed, 24 May 2000 08:29:35 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id IAA49636 for ; Wed, 24 May 2000 08:38:58 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E9.00457C53 ; Wed, 24 May 2000 08:38:58 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568E9.004579C3.00@d54mta04.raleigh.ibm.com> Date: Wed, 24 May 2000 08:38:50 -0400 Subject: RE: Issue 3601 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: R[O!!Zb)!!bY"e9M/N!! Michi Henning on 05/23/2000 05:06:25 PM > > On Tue, 23 May 2000 butek@us.ibm.com wrote: > > > > I suspect that here, as in its lack of orbid parameter, the Java mapping > > > fails to live up to the CORBA spec (from ptc/00-03-02, sec. 4.5.1): > > > > > > Before ORB_init returns, it will remove from the arg_list parameter > > > all strings that match the -ORB pattern described above and > > > that are recognized by that ORB implementation, along with any > > > associated sequential parameter strings. If any strings in arg_list > > > that match this pattern are not recognized by the ORB implementation, > > > ORB_init will raise the BAD_PARAM system exception instead. > > > > > > Ah. I thought this was a C/C++-only thing. Thanks for pointing it out. > > However, I wouldn't complain about the Java mapping in this case. I'd > > complain that the spec was written too closely to C++. There are a number > > of languages where an arg_list argument cannot be modified by the called > > method. The spec chooses to ignore these languages, so the mappings have > > no choice but to deviate. > > Huh? That's not right, I think. This is purely a mapping issue. If you > can't modify argc/argv directly in Java, then the language mapping must > take care to pass something to ORB_init() that can be modified, that's all. OK, I'll concede that point; however, it still upsets me from time to time to see how C/C++-centric CORBA is. But ORB_init is PIDL. I've always understood that mappings can do with PIDL whatever they please, whatever suits the language best. > > The Java mapping has stomped on things here in more than one >way. For > example, the arguments are mapped to a property set, so any ordering >that > was present for the arguments on the command-line (and that ordering > may be significant) is thrown away. This is not true. Here's the application version of ORB_init: ORB.init (String[] args, Properties props); props is a programmatic parameter. args is intended to be the parameter to main; the equivalent of C++'s argv/argc. So the Java mapping isn't broken in this respect. It's simply 'broken' because init cannot change args. It can change the contents but not the array itself, which is really what the spec wants. > That's simply an incorrect mapping > given that the arguments are sequence, not a set. It would be nice > to fix the Java mapping, really... > In any case, this is tangential to the original question, which is wondering what we should do with the args that are passed to ORB initializers via ORBInitInfo. Should the ORB args be stripped before the ORB initializers see the list or not? Or should we leave it as "may or may not" as the spec currently states? Russell Butek butek@us.ibm.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3601 proposal Date: Wed, 24 May 2000 13:15:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: p9W!!QX"!!=-Qd9I1Ke9 > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > In any case, this is tangential to the original question, which is > wondering what we should do with the args that are passed to ORB > initializers via ORBInitInfo. Should the ORB args be > stripped before the > ORB initializers see the list or not? Or should we leave it > as "may or may not" as the spec currently states? I think it is becoming apparent that neither is adequate. I don't think the arguments in their raw form should be available at all. Instead, I propose that there should be accessors for a particular argument by name. This would be an operation on ORBInitInfo - something like: typedef sequence ArgumentValues; ArgumentValues argument(in string arg_name, unsigned long n_values); For instance: orb_init_info->argument("id", 1) would request the value of the -ORBid argument, saying that it is expected to have a single accompanying value. This would both access arguments and serve as a way of declaring how many values should accompany them. If the same argument is requested more than once, subsequent accesses must specify the same number of values. This gives the orb the necessary hints to parse the arguments, remove the ones it should, and by the end of orb initialization it permits the orb to diagnose any -ORBxxx arguments that were not expected. Paul Reply-To: From: "Nick Sharman" To: Subject: RE: Issue 3601 proposal Date: Thu, 25 May 2000 09:02:38 +0100 Message-ID: <009501bfc61f$985dc070$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BEBF@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: G,#e9h_`!!KaC!!]B~e9 > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: Wednesday, May 24, 2000 6:16 PM > To: interceptors-ftf@omg.org > Subject: RE: Issue 3601 proposal > > > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > > In any case, this is tangential to the original question, which is > > wondering what we should do with the args that are passed to ORB > > initializers via ORBInitInfo. Should the ORB args be > > stripped before the > > ORB initializers see the list or not? Or should we leave it > > as "may or may not" as the spec currently states? > > I think it is becoming apparent that neither is adequate. > I don't think the arguments in their raw form should be available at all. > > Instead, I propose that there should be accessors for a > particular argument > by name. > This would be an operation on ORBInitInfo - something like: > > typedef sequence ArgumentValues; > ArgumentValues argument(in string arg_name, unsigned long n_values); > > For instance: > > orb_init_info->argument("id", 1) > > would request the value of the -ORBid argument, saying that it is expected > to have a single accompanying value. > > This would both access arguments and serve as a way of declaring how many > values should accompany them. If the same argument is requested more than > once, subsequent accesses must specify the same number of values. > > This gives the orb the necessary hints to parse the arguments, remove the > ones it should, and by the end of orb initialization it permits the orb to > diagnose any > -ORBxxx arguments that were not expected. > > Paul > I agree we need something like this. The current core spec. for args is a bit vague on whether the following are allowed: A) 'option' arguments (no value expected; presence of "-ORBarg" is enough) - or should we use '-ORBarg YES' or similar? B) repeated arguments '-ORBarg v1 -ORBarg v2 -ORBarg v3' - or should we use '-ORBarg v1,v2,v3' or similar? C) multiword arguments '-ORBarg w1 w2 w3' aren't allowed - although I think we should use '-ORBarg "w1 w2 w3"'. Paul, does n_values > 1 indicate (B) or (C)? And does it mean "up to" or "exactly"? We could use an n_values of 0 either to mean "this is an option arg" or to mean "zero or more repeated args" - possibly more useful/common than a fixed bound. Paul doesn't say how ORBInitInfo::argument indicates "arg not found" - one way would be just to return an empty sequence, but that wouldn't tell us much about 'option' arguments - raises (ArgumentNotFound)? How about: exception ArgumentNotFound{}; typedef sequence ArgumentValues; typedef unsigned short ArgumentKind; const ArgumentKind OPTION_ARG = 0; const ArgumentKind SINGLE_VALUE_ARG = 1; const ArgumentKind MULTI_VALUE_ARG = 2; ArgumentValues argument(in string arg_name, in ArgumentKind arg_kind) raises (ArgumentNotFound); MULTI_VALUE_ARG accepts zero or more - caller can check length of returned sequence and take avoiding action (what?) Regards Nick From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA21806 for ; Thu, 25 May 2000 08:43:35 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id JAA68404 for ; Thu, 25 May 2000 09:03:49 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568EA.0047C227 ; Thu, 25 May 2000 09:03:47 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568EA.0047BC96.00@d54mta04.raleigh.ibm.com> Date: Thu, 25 May 2000 09:03:30 -0400 Subject: RE: Issue 3601 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: p:X!!mM>e92Wcd9e18e9 "Nick Sharman" on 05/25/2000 03:02:38 AM > > > > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > > > > In any case, this is tangential to the original question, which is > > > wondering what we should do with the args that are passed to ORB > > > initializers via ORBInitInfo. Should the ORB args be > > > stripped before the > > > ORB initializers see the list or not? Or should we leave it > > > as "may or may not" as the spec currently states? > > > > I think it is becoming apparent that neither is adequate. > > I don't think the arguments in their raw form should be available at all. > > > > Instead, I propose that there should be accessors for a > > particular argument > > by name. > > This would be an operation on ORBInitInfo - something like: > > > > typedef sequence ArgumentValues; > > ArgumentValues argument(in string arg_name, unsigned long n_values); > > > > For instance: > > > > orb_init_info->argument("id", 1) > > > > would request the value of the -ORBid argument, saying that it is expected > > to have a single accompanying value. > > > > This would both access arguments and serve as a way of declaring how many > > values should accompany them. If the same argument is requested more than > > once, subsequent accesses must specify the same number of values. > > > > This gives the orb the necessary hints to parse the arguments, remove the > > ones it should, and by the end of orb initialization it permits the orb to > > diagnose any > > -ORBxxx arguments that were not expected. > > > > Paul > > > I agree we need something like this. The current core spec. for args is a > bit vague on whether the following are allowed: I certainly agree that the current core spec is vague, as you point out. The Java mapping spec is also vague. In Java 'arguments' can be passed to ORB.init via arguments or a Properties object. Properties are hashtables of pairs and there can only be one entry with a particular key. This throws your first option in B) out the window. And this isn't a hypothetical situation. See the -ORBInitRef discussion in the INS spec. Given that these specs, particularly the core, are vague, is it this FTF's place to tighten it up, or should that be done in the core and we wait for their results before modifying the interceptor spec? > > A) 'option' arguments (no value expected; presence of "-ORBarg" is enough) > - or should we use '-ORBarg YES' or similar? > > B) repeated arguments '-ORBarg v1 -ORBarg v2 -ORBarg v3' > - or should we use '-ORBarg v1,v2,v3' or similar? > > C) multiword arguments '-ORBarg w1 w2 w3' aren't allowed > - although I think we should use '-ORBarg "w1 w2 w3"'. > > Paul, does n_values > 1 indicate (B) or (C)? And does it mean "up >to" or > "exactly"? > > We could use an n_values of 0 either to mean "this is an option arg" >or to > mean "zero or more repeated args" - possibly more useful/common than >a fixed > bound. Repeated args are risky. What if a user intermingled ORB args and their own args? -ORBId XXX -ORBarg1 A B -Debug true -ORBarg2 C D If arg1's arglist were 0..n args then how does the ORB decide that '-Debug' ends the args list for arg1? Or if arg2's arglist were 0..n, then is D and arg2 arg or an application arg? The ORB would be clueless. The ORB initializer would have a much better chance of making this decision. We could mandate that all args on CORBA applications must begin with "-" or "/" or some such, but is that wise? Think of things like compilers. We write: 'cpp myapp.cpp' or 'javac myapp.java'. Mandating the "-" or "/" would mean apps that follow the compiler args convention and that happen to use an ORB would have to change to something like 'cpp -File myapp.cpp'. > > Paul doesn't say how ORBInitInfo::argument indicates "arg not found" >- one > way would be just to return an empty sequence, but that wouldn't >tell us > much about 'option' arguments - raises (ArgumentNotFound)? > > How about: > > exception ArgumentNotFound{}; > typedef sequence ArgumentValues; > > typedef unsigned short ArgumentKind; > const ArgumentKind OPTION_ARG = 0; > const ArgumentKind SINGLE_VALUE_ARG = 1; > const ArgumentKind MULTI_VALUE_ARG = 2; > > ArgumentValues argument(in string arg_name, in ArgumentKind >arg_kind) > raises (ArgumentNotFound); > > MULTI_VALUE_ARG accepts zero or more - caller can check length of returned > sequence and take avoiding action (what?) > I'm not sure I understand the whole point of this exercise. What's the problem with passing the whole arglist to the ORB initializer? It's the one that is in the best position to determine how to handle its own arguments. Is it so that those arguments can be stripped along with the ORB arguments? First, this assumes ORB initializer arguments are ORB arguments (and I'm on the fence with regard to this). Second, the ORB initializer could do the stripping itself. I've already shown that, in the case of repeated arguments, the ORB is in no position to do any sort of parsing, much less stripping. > Regards > Nick > From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3601 proposal Date: Thu, 25 May 2000 11: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: A%id9&N7e9(0F!!nmF!! > From: Nick Sharman [mailto:nick.sharman@peerlogic.com] > I agree we need something like this. The current core spec. > for args is a bit vague on whether the following are allowed: > > A) 'option' arguments (no value expected; presence of > "-ORBarg" is enough) > - or should we use '-ORBarg YES' or similar? > > B) repeated arguments '-ORBarg v1 -ORBarg v2 -ORBarg v3' > - or should we use '-ORBarg v1,v2,v3' or similar? > > C) multiword arguments '-ORBarg w1 w2 w3' aren't allowed > - although I think we should use '-ORBarg "w1 w2 w3"'. > > Paul, does n_values > 1 indicate (B) or (C)? And does it > mean "up to" or "exactly"? Actually what I proposed was a bit off-the-cuff. I had (C) in mind. But after reviewing the spec, I agree that (C) with n > 1 is not legal. I do believe n=0 and n=1 are both legal (and useful) as the spec is currently written. With the restriction that n=0 or n=1, the api can be considerably simplified. There could simply be two operations. One implies n=0 and returns a boolean. One implies n=1 and returns a (possibly zero length) string. I am certainly not attached to a particular api at this stage - just exploring the concept. > > We could use an n_values of 0 either to mean "this is an > option arg" or to > mean "zero or more repeated args" - possibly more > useful/common than a fixed > bound. > > Paul doesn't say how ORBInitInfo::argument indicates "arg not > found" - one > way would be just to return an empty sequence, but that > wouldn't tell us > much about 'option' arguments - raises (ArgumentNotFound)? yes, I was intentionally vague on that. Again, I am not attached to any particular api yet. > > How about: > > exception ArgumentNotFound{}; > typedef sequence ArgumentValues; > > typedef unsigned short ArgumentKind; > const ArgumentKind OPTION_ARG = 0; > const ArgumentKind SINGLE_VALUE_ARG = 1; > const ArgumentKind MULTI_VALUE_ARG = 2; > > ArgumentValues argument(in string arg_name, in > ArgumentKind arg_kind) > raises (ArgumentNotFound); > > MULTI_VALUE_ARG accepts zero or more - caller can check > length of returned > sequence and take avoiding action (what?) I do think the multi-value case presents problems that we don't need to deal with. In our orb today we deal with multi-values as a single value that is a comma separated list. I think that is sufficiently powerful. How about this: exception ArgumentNotFound{}; exception OptionValueConflict{}; bool is_option_argument(in string name) raises(OptionValueConflict); bool is_value_argument(in string name) raises(OptionValueConflict); string value_argument(in string name) raises(ArgumentNotFound, OptionValueConflict); A call to is_option_argument will return true if -ORBname is present in the arglist. A true return implicitly types the name as an option, and will result in that option being removed from the arglist. Subsequent calls to is_option_argument will return true, and calls to is_value_argument will return ArgumentOptionConflict. A call to is_value_argument will return true if -ORBname is present in the arglist. A value adjacent to the is associated with it. (Could be in "-ORBnamexxx" syntax, "-ORBname xxx" syntax, or "-ORBname" "xxx" syntax. The "-ORBname" "xxx" only includes the "xxx" if it doesn't start with a "-".) The value could be the null string. A true return implicitly types the name as a value argument, and will result in that option and value being removed from the arglist. Subsequent calls to is_value_argument will return true, and calls to is_option_argument will return ArgumentOptionConflict. A call to value_argument will implicitly call is_value_argument, and then if the result is true, return the corresponding value. If false, it will return a null string. Paul Date: Fri, 26 May 2000 07:40:34 +1000 (EST) From: Michi Henning To: butek@us.ibm.com cc: interceptors-ftf@omg.org Subject: RE: Issue 3601 proposal In-Reply-To: <852568EA.0047BC96.00@d54mta04.raleigh.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: VjSd9$=[d9?\!e9*)5!! On Thu, 25 May 2000 butek@us.ibm.com wrote: > Given that these specs, particularly the core, are vague, is it this FTF's > place to tighten it up, or should that be done in the core and we wait for > their results before modifying the interceptor spec? If we come up with a reasonably modification to the core, I'm pretty sure that the core RTF would be greatful for it... 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 Reply-To: From: "Nick Sharman" To: Subject: RE: Issue 3601 proposal Date: Fri, 26 May 2000 09:49:32 +0100 Message-ID: <001201bfc6ef$4fc817e0$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BECE@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: P]Nd96]pd9d3Pe9PV5e9 > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: Thursday, May 25, 2000 4:03 PM > To: interceptors-ftf@omg.org > Subject: RE: Issue 3601 proposal > > > > From: Nick Sharman [mailto:nick.sharman@peerlogic.com] > > > I agree we need something like this. The current core spec. > > for args is a bit vague on whether the following are allowed: > > > > A) 'option' arguments (no value expected; presence of > > "-ORBarg" is enough) > > - or should we use '-ORBarg YES' or similar? > > > > B) repeated arguments '-ORBarg v1 -ORBarg v2 -ORBarg v3' > > - or should we use '-ORBarg v1,v2,v3' or similar? > > > > C) multiword arguments '-ORBarg w1 w2 w3' aren't allowed > > - although I think we should use '-ORBarg "w1 w2 w3"'. > > > > Paul, does n_values > 1 indicate (B) or (C)? And does it > > mean "up to" or "exactly"? > > Actually what I proposed was a bit off-the-cuff. I had (C) in mind. > But after reviewing the spec, I agree that (C) with n > 1 is not legal. > > I do believe n=0 and n=1 are both legal (and useful) as the spec is > currently written. > Russel has pointed out that the ORB itself supports a (B)-style parameter (-ORBInitRef), and the problems this causes for Java ORB - issue #3643. Is that a precedent for interceptors, or should we stomp on it? > With the restriction that n=0 or n=1, the api can be considerably > simplified. > There could simply be two operations. One implies n=0 and returns > a boolean. > One implies n=1 and returns a (possibly zero length) string. > > I am certainly not attached to a particular api at this stage - just > exploring the concept. > > > > > We could use an n_values of 0 either to mean "this is an > > option arg" or to > > mean "zero or more repeated args" - possibly more > > useful/common than a fixed > > bound. > > > > Paul doesn't say how ORBInitInfo::argument indicates "arg not > > found" - one > > way would be just to return an empty sequence, but that > > wouldn't tell us > > much about 'option' arguments - raises (ArgumentNotFound)? > > yes, I was intentionally vague on that. Again, I am not attached to > any > particular api yet. > > > > > How about: > > > > exception ArgumentNotFound{}; > > typedef sequence ArgumentValues; > > > > typedef unsigned short ArgumentKind; > > const ArgumentKind OPTION_ARG = 0; > > const ArgumentKind SINGLE_VALUE_ARG = 1; > > const ArgumentKind MULTI_VALUE_ARG = 2; > > > > ArgumentValues argument(in string arg_name, in > > ArgumentKind arg_kind) > > raises (ArgumentNotFound); > > > > MULTI_VALUE_ARG accepts zero or more - caller can check > > length of returned > > sequence and take avoiding action (what?) > > I do think the multi-value case presents problems that we don't > need to deal > with. > In our orb today we deal with multi-values as a single value that > is a comma > separated list. I think that is sufficiently powerful. > > How about this: > > exception ArgumentNotFound{}; > exception OptionValueConflict{}; > bool is_option_argument(in string name) > raises(OptionValueConflict); > bool is_value_argument(in string name) > raises(OptionValueConflict); > string value_argument(in string name) > raises(ArgumentNotFound, > OptionValueConflict); > > A call to is_option_argument will return true if -ORBname is > present in the > arglist. A true return implicitly types the name as an option, and > will > result in that option being removed from the arglist. Subsequent > calls to > is_option_argument will return true, and calls to is_value_argument > will > return ArgumentOptionConflict. > > A call to is_value_argument will return true if -ORBname is present > in the > arglist. A value adjacent to the is associated with it. (Could be in > "-ORBnamexxx" syntax, > "-ORBname xxx" syntax, or "-ORBname" "xxx" syntax. The "-ORBname" > "xxx" only > includes the "xxx" if it doesn't start with a "-".) The value could > be the > null string. A true return implicitly types the name as a value > argument, > and will result in that option and value being removed from the > arglist. > Subsequent calls to is_value_argument will return true, and calls to > is_option_argument will return ArgumentOptionConflict. > > A call to value_argument will implicitly call is_value_argument, > and then if > the result is true, return the corresponding value. If false, it > will return > a null string. > > Paul > I think we need to place one new restriction on the format of the > command line. Consider: myapp -ORBfoo -ORBbar stuff Unless you know all the parameter formats, you can't tell whether this is: one ORB arg "foo" (value "-ORBbar"); one app arg "stuff" two ORB args "f" (value "oo") and "bar" (value "stuff"); no app args two ORB args "f" (value "oo") and "b" (value "ar"); one app arg "stuff" Gradually, Paul's suggested *_argument calls will help the ORB strip out args it doesn't understand. However, I think it has to recognize its own args before any pre_init & post_init calls, otherwise it probably won't be in the right state (e.g. for calls to resolve_initial_references). What if it understands -ORBbar but not -ORBf*? If so, it doesn't know whether the -ORBbar is part of the first (presumably PI) arg or its own arg. Therefore, I suggest that, if the value part of an ORB arg starts with -ORB, it must be part of the same string in the args array. With this restriction, the ORB can scan for -ORBbar without worrying that it's part of someone else's arg. If the user really wanted "-ORBbar" to be the value of an other arg, they would have to write: myapp -ORBfoo-ORBbar stuff or: myapp "-ORBfoo -ORBbar" stuff This slight restriction means we can avoid an extra method on the initial interceptor that would return something similar in purpose to a getopts() pattern - or would anyone prefer that? I won't raise the subject of argument name clashes between interceptors and/or ORB implementations... Regards Nick Date: Tue, 18 Jul 2000 07:04:15 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: interceptors-ftf@omg.org Subject: [Fwd: interceptors ftf issue 3601] Content-Type: multipart/mixed; boundary="------------122839A66452F71A653815F0" X-UIDL: c/Ke9&96!!,\)e9V,0!! Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA29143 for ; Mon, 17 Jul 2000 23:36:16 -0700 (PDT) Received: from sunmail1.Sun.COM (sunmail1 [129.145.1.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA27201 for ; Mon, 17 Jul 2000 23:36:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA29069 for ; Mon, 17 Jul 2000 23:36:16 -0700 (PDT) Received: from janus.ooc.com.au (styx.ooc.com.au [210.8.155.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA08399 for ; Tue, 18 Jul 2000 00:36:12 -0600 (MDT) Received: from errigal.ooc.com.au (IDENT:root@errigal.ooc.com.au [10.1.1.5]) by janus.ooc.com.au (8.9.3/8.9.3) with ESMTP id QAA13451 for ; Tue, 18 Jul 2000 16:36:05 +1000 Received: (from tmcf@localhost) by errigal.ooc.com.au (8.9.3/8.9.3) id QAA21939 for harold.carr@sun.com; Tue, 18 Jul 2000 16:36:05 +1000 Date: Tue, 18 Jul 2000 16:36:05 +1000 From: Ted McFadden To: Harold Carr Subject: Re: interceptors ftf issue 3601 Message-ID: <20000718163605.D23760@ooc.com.au> References: <397393A5.9BC48E2F@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <397393A5.9BC48E2F@sun.com>; from harold.carr@sun.com on Mon, Jul 17, 2000 at 04:15:49PM -0700 On Mon, Jul 17, 2000 at 04:15:49PM -0700, Harold Carr wrote: > Could you supply precise/complete changes/additions/deletions to > ptc/2000-04-05 for the issue you raised. You can find it and its > archive by following links in: > > http://cgi.omg.org/issues/interceptors-ftf.html > > THanks, > Harold Hello Harold, The issue generated far more discussion than I expected and a new issue will need to be raised by someone to address the bigger picture. However in the context of the specific clarification I asked for, I give a choice of 3 resolutions, the second 2 of which were in email from Russell Butek to the ftf list. To clarify ptc/2000-04-05 page 21-42 Section 21.7.2.3 Arguments: Current Text: This attribute contains the arguments passed to ORB_init. They may or may not contain the ORB's arguments. Resolution Choices: 1. No Change. The discussion indicates a new issue needs to be raised to address this at a higher level. 2. This attribute contains the arguments passed to ORB_init. It may or may not contain the arguments which the ORB recognizes. It shall contain all arguments passed to ORB_init which the ORB does not recognize. 3. This attribute shall contain all the arguments that are passed to ORB_init. Cheers, Ted -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4 904 Stanley St. +61-7-3891-5744 East Brisbane 4169, QLD. Australia Date: Tue, 29 Oct 2002 16:41:27 -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: Issues 3601 and 5690 Issues 3601 and 5690 (see below) appear to be very closely related if not the same. My suggestion is that we close issue 3601 since it just asks for an interpretation and concentrate on a resolution of the real issue for 5690 which contains specific suggestions. So the resolution of 3601 will then be: "There is indeed an ambiguity here. This ambiguity is mentioned with more specific suggestions for fixing it in issue 5690. So this issue is closed no change with the acknowledgement that there is ambiguity and resolution of the ambiguity is deferred to Issue 5690." Comments? Jishnu. __________________________________________________________________ Issue 3601: Portable Interceptors: 9.2.3 text describing `Arguments' (interceptors-rtf) Click http://cgi.omg.org/issues/issue3601.txt for this issue's archive. Source: DSTC (Mr. Ted McFadden, mcfadden@dstc.edu.au) Nature: Uncategorized Issue Severity: Minor Summary: The text in section 9.2.3 / page 9-71 describing the arguments attribute to ORBInitInfo could use some more precise wording. It reads: "This attribute contains the arguments passed to ORB_init. They may or may not contain the ORB's arguments." I take this to mean that any ORB_init arguments that applied to the ORB instance being created may not be present. All other strings passed to ORB_init will be present so initialisation strings can be passed to the interceptors through ORB_init. With the current text it is possible to think that you may not get *any* of the arguments to ORB_init. _______________________________________________________________________ Issue 5690: ORBInitInfo::arguments() underspecified (corba-rtf) Click http://cgi.omg.org/issues/issue5690.txt for this issue's archive. Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: 21.7.2.3 states: "This attribute contains the arguments passed to ORB_init. They may or may not contain the ORB's arguments." First, what good does this do? A portable application can't depend on anything useful being returned by this attribute. This should be changed to state that ORBInitInfo::arguments() returns the original unmodified argv parameter that was passed to ORB_init. ----- Second, this attribute really ought to be read-write, so that an Interceptor implementation can find and strip out arguments that are intended for the Interceptor. Alternatively, we should specify a standard prefix for arguments that are recognized and processed by interceptors, so that the ORB and client code can be explicitly coded to recognize and ignore them. Date: Tue, 05 Nov 2002 17:29:09 -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 3601 Proposed Resolution The following resolution will appear in a vote in the near future unless there is any serious technical objection to it. Jishnu. _________________________________________________________________________ Issue 3601: Portable Interceptors: 9.2.3 text describing `Arguments' (interceptors-rtf) Click here for this issue's archive. Source: DSTC (Mr. Ted McFadden, mcfadden@dstc.edu.au) Nature: Uncategorized Issue Severity: Minor Summary: The text in section 9.2.3 / page 9-71 describing the arguments attribute to ORBInitInfo could use some more precise wording. It reads: "This attribute contains the arguments passed to ORB_init. They may or may not contain the ORB's arguments." I take this to mean that any ORB_init arguments that applied to the ORB instance being created may not be present. All other strings passed to ORB_init will be present so initialisation strings can be passed to the interceptors through ORB_init. With the current text it is possible to think that you may not get *any* of the arguments to ORB_init. Resolution: Issue 5690 addresses this in a more specific focused way. So close this issue and merge its discussion into 5690. Revised Text: Actions taken: Merge with 5690 and close this issue.