Issue 1241: / in prefix pragma? (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: currently, #pragma prefix is completely unconstrained and can contain any character. This includes potentially troublesome things such as space and "/", or non-printing characters. I would suggest to define a syntax for #pragma prefix. In particular, I think that "/" should be forbidden in a prefix. This is because otherwise, given a repository ID, I cannot work out where the prefix ends and the scoped name starts. In addition, things that cannot normally be part of file names or identifiers should probably be forbidden as well, otherwise we could get problems with things like the class path in Java. Resolution: Revised Text: Actions taken: April 27, 1998: received issue June 25, 1998: moved from port-rtf to orb_revision February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Mon, 27 Apr 1998 07:11:11 +1000 (EST) From: Michi Henning To: issues@omg.org, port-rtf@omg.org Subject: / in prefix pragma? Hi, currently, #pragma prefix is completely unconstrained and can contain any character. This includes potentially troublesome things such as space and '/', or non-printing characters. I would suggest to define a syntax for #pragma prefix. In particular, I think that '/' should be forbidden in a prefix. This is because otherwise, given a repository ID, I cannot work out where the prefix ends and the scoped name starts. In addition, things that cannot normally be part of file names or identifiers should probably be forbidden as well, otherwise we could get problems with things like the class path in Java. Maybe the it would make sense to restrict the prefix to contain ASCII alphabetics, digits, underscore, and dot? Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Mon, 27 Apr 1998 11:53:56 -0400 From: Bob Kukura Organization: IONA Technologies To: issues@omg.org, port-rtf@omg.org Subject: Re: issue1241. PORT RTF ISSUE References: <3.0.32.19980427105647.006d9968@emerald.omg.org> This proposed change would defeat one of the purposes of the prefix pragma, which was to allow IDL definitions to be moved from one module to another while preserving their existing RepositoryIds. RepositoryIds were never intended to be mappable back to scoped names. If such a mapping was required, alternative RepositoryId formats, such as UUIDs, would not be possible. Once generated, RepositoryIds should be treated as opaque (at least until versioning is added to CORBA). -Bob Juergen Boldt wrote: > > This is issue # 1241 > > / in prefix pragma? > > currently, #pragma prefix is completely unconstrained and can > contain > any character. This includes potentially troublesome things such as > space > and '/', or non-printing characters. > > I would suggest to define a syntax for #pragma prefix. In > particular, I think > that '/' should be forbidden in a prefix. This is because otherwise, > given > a repository ID, I cannot work out where the prefix ends and the > scoped > name starts. In addition, things that cannot normally be part of > file names > or identifiers should probably be forbidden as well, otherwise we > could > get problems with things like the class path in Java. > > ================================================================ > > Juergen Boldt > Technical Process Manager > > Object Management Group Tel. +1-508-820 4300 ext. 132 > Framingham Corporate Center Fax: +1-508-820 4303 > 492 Old Connecticut Path Email: juergen@omg.org > Framingham, MA 01701 > > ================================================================ Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 28 Apr 1998 06:25:22 +1000 (EST) From: Michi Henning To: Bob Kukura cc: port-rtf@omg.org Subject: Re: issue1241. PORT RTF ISSUE On Mon, 27 Apr 1998, Bob Kukura wrote: > This proposed change would defeat one of the purposes of the prefix > pragma, which was to allow IDL definitions to be moved from one > module > to another while preserving their existing RepositoryIds. Hmmm... Let me see. Assume we have #pragma prefix "a/b/c" module d { interface e {}; }; Bob, unless I misunderstand something, what you are saying then is that by permitting a slash in the prefix, I can change the above to #pragma prefix "a/b" module c { module d { interface e {}; }; }; The only possible "movement" would be up or down the existing prefix-name path like in the example above. Do I have the correct picture? If so, the ability to do this strikes me as not very useful, at least at first glance. Did anyone come up with realistic scenarios that would require this? > RepositoryIds were never intended to be mappable back to scoped names. > If such a mapping was required, alternative RepositoryId formats, such > as UUIDs, would not be possible. Once generated, RepositoryIds should > be treated as opaque (at least until versioning is added to CORBA). I never suggested this to be able to map the repository IDs back to scoped names. The issue came up in Fnorb (our Python) ORB, which relies extensively on an interface repository for its work. The inability to distinguish where the prefix ends and the scoped name starts makes life difficult for Fnorb at times. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Mon, 27 Apr 1998 11:45:34 -0700 (PDT) From: Mail Delivery Subsystem To: Subject: Returned mail: unknown mailer error 1 Auto-Submitted: auto-generated (failure) The original message was received at Mon, 27 Apr 1998 11:45:34 -0700 (PDT) from mercury.healtheon.com [10.2.1.2] ----- The following addresses had permanent fatal errors ----- "|/usr/local/bin/sn healtheon.corba-interest" (expanded from: ) ----- Transcript of session follows ----- sh: /usr/local/bin/sn: not found 554 "|/usr/local/bin/sn healtheon.corba-interest"... unknown mailer error 1 Reporting-MTA: dns; hscape.healtheon.com Received-From-MTA: DNS; mercury.healtheon.com Arrival-Date: Mon, 27 Apr 1998 11:45:34 -0700 (PDT) Final-Recipient: RFC822; X-Actual-Recipient: RFC822; |/usr/local/bin/sn healtheon.corba-interest@hscape.healtheon.com Action: failed Status: 5.0.0 Last-Attempt-Date: Mon, 27 Apr 1998 11:45:34 -0700 (PDT) Return-Path: Received: from mercury.healtheon.com (mercury.healtheon.com [10.2.1.2]) by hscape.healtheon.com (8.8.8/8.8.7) with ESMTP id LAA13936 for ; Mon, 27 Apr 1998 11:45:34 -0700 (PDT) Received: from emerald (emerald.omg.org [192.67.184.65]) by mercury.healtheon.com (8.8.8/8.8.7) with SMTP id LAA06761 for ; Mon, 27 Apr 1998 11:53:11 -0700 (PDT) Received: from bronze.omg.org by emerald (SMI-8.6/SMI-SVR4) id OAA26624; Mon, 27 Apr 1998 14:48:47 -0400 Message-Id: <3.0.32.19980427143946.006e4814@emerald.omg.org> X-Sender: juergen@emerald.omg.org X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 27 Apr 1998 14:39:46 -0400 To: issues@omg.org, boca-rtf@omg.org From: Juergen Boldt Subject: issue1244 -- BOCA RTF ISSUE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" This is issue # 1244 OBV/inheritance restriction clarification The OMG Objects By Value, document orbos/98-01-18, defines restrictions on inheritance relationships starting on page 5-26, section 5.3.2.1. This section of the Object By Value document includes a summarization table for allowable inheritance relationships. (This specifies that an interface may inherit from multiple interfaces, no abstract values, and no stateful values. An abstract value may support multiple interfaces and abstract values. A stateful value may support multiple interfaces and abstract values, inherit from a single stateful value.) The BOCA document, page 90, defines constraints on specification inheritance, including that "a type can inherit from other types and/or idl interfaces". This statement, and the other contraints, may not adequately reflect the semantic constraints added by the Objects By Value specification. This issue was addressed in the BOCA errata document bom/98-02-17, but was inadvertently lost in the transcription to the final errata document. ================================================================ Juergen Boldt Technical Process Manager Object Management Group Tel. +1-508-820 4300 ext. 132 Framingham Corporate Center Fax: +1-508-820 4303 492 Old Connecticut Path Email: juergen@omg.org Framingham, MA 01701 ================================================================ Return-Path: X-Sender: jeffm@visigenic.com Date: Tue, 28 Apr 1998 08:04:05 -0700 To: Bob Kukura , Michi Henning From: "Jeff Mischkinsky" Subject: Re: issue1241. PORT RTF ISSUE Cc: port-rtf@omg.org At 05:02 PM 4/27/98 -0400, Bob Kukura wrote: >Hi Michi, > >Michi Henning wrote: >> >> On Mon, 27 Apr 1998, Bob Kukura wrote: >> >> >> > RepositoryIds were never intended to be mappable back to scoped names. >> > If such a mapping was required, alternative RepositoryId formats, such >> > as UUIDs, would not be possible. Once generated, RepositoryIds should >> > be treated as opaque (at least until versioning is added to CORBA). >> >> I never suggested this to be able to map the repository IDs back to >> scoped names. The issue came up in Fnorb (our Python) ORB, which relies >> extensively on an interface repository for its work. The inability >> to distinguish where the prefix ends and the scoped name starts >> makes life difficult for Fnorb at times. > >Distinguishing the prefix from the rest goes a long way towards mapping >back to the scoped name. If we had intended this to be possible, I >think we would have made the prefix a separate component and separated >from the scoped name by a ':'. > >I haven't run into a need to parse the RepositoryIds, and its still not >clear to me why not being able to do this is making your life >difficult. Even if you could do this for IDL format RepositoryIds, what >would you do with other formats? > >-Bob In Java, the OBV spec makes use of repository id's that are in "standard IDL:" format as a default way to find a class that implements a particular valuetype, as identified by its repid. Note: that this is not the ONLY way to find the class, an explicit map can be set up, but it is certainly the easiest. Here is the relevant excerpt from the spec: (section 6.4) The following algorithm will be followed by the ORB: If the RepositoryId is a standard IDL repository id (i.e. it starts wit h then attempt to interpret it as a fully scoped class name by stripping off th e header an d version information trailer, and replacing th es which separate the module names wit hs. If this is not successful, then look up the class name in the RepositoryID to class name map. If this is not successful, then raise the MARSHAL exception. The IDL native type ValueFactory is mapped in Java to java.lang.Class. A null is returned when register_value_factory() is called and no previous RepositoryId wawishes to explicitly register a particular Value Factory with some RepositoryID. For example, this could be done by an s registered. As usual, it is a tools issue, as to how RepositoryIDs are registered with classes. It is our assumption that i n in a server, by pre-loading the ORB runtime, etc.. jeff Jeff Mischkinsky email: jeffm@visigenic.com Senior Software Architect voice: +1(650)312-5158 Borland International, Inc. fax: +1(650)286-2475 951 Mariner's Island Blvd. web: http://www.visigenic.com San Mateo, CA 94404 the vast majority of times, the above default implicit registration policies will be adequate. A tool is free to arrange to have the ORB Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 29 Apr 1998 17:08:24 +1000 (EST) From: Michi Henning Reply-To: Michi Henning To: Bob Kukura cc: port-rtf@omg.org Subject: Re: issue1241. PORT RTF ISSUE On Mon, 27 Apr 1998, Bob Kukura wrote: > > > This proposed change would defeat one of the purposes of the prefix > > > pragma, which was to allow IDL definitions to be moved from one module > > > to another while preserving their existing RepositoryIds. > [...] > > Lets say I sent you the following IDL: > > module a { > module b { > interface c {}; > }; > }; > > and you already had a module "a". You could change the IDL I sent you > to: > > module another_a { > #pragma prefix a > module b { > interface c {}; > }; > }; > > and still interoperate with my implementation of the IDL. This might > not be a likely scenario if everyone always uses a domain-name prefix. > But modules sometimes need to be renamed, split up, or combined for > other reasons. One example is when a C++ compiler doesn't support > namespaces and things need to be moved to the same module to eliminate > cyclic cross-module dependencies. Thanks for the explanation Bob! I was unaware of that motivation. I'm not sure it's all that nice do this. Personally, I would find it rather confusing... But I can live with it ;-) Also, with these semantics, the prefix does *not* guarantee me a globally unique repository ID, *even* if no-one uses the same prefix. Here is why: Developer A: #pragma prefix "a/b" // Prefix unique to Developer A module c { interface d {}; }; Developer B: #pragma prefix "a/b/c" // Prefix unique to Developer B exception d { ... }; We now have two identical repository IDs that denote different types, even though each IDL specification uses different prefixes. I'm the first to admit though that this case is so pathological that it isn't worth worrying about... > I haven't run into a need to parse the RepositoryIds, and its still not > clear to me why not being able to do this is making your life > difficult. Even if you could do this for IDL format RepositoryIds, what > would you do with other formats? You are right of course, and I'll eat humble pie on that one. Turns out that Fnorb needs to do things a little differently, not CORBA ;-) So, there is no need to exclude slashes from prefixes, I'll withdraw that suggestion. Question: What about other "nasty" characters inside prefixes? For example, non-printing characters or spaces? Given that all of the repository ID, except for the prefix, is composed from a limited character set, shouldn't prefixes be limited to some sensible character set as well? Do we really want to permit form feeds, newlines, tabs, ASCII BEL, etc in prefixes? Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Wed, 29 Apr 1998 15:16:25 -0400 From: Bob Kukura Organization: IONA Technologies To: Michi Henning CC: port-rtf@omg.org Subject: Re: issue1241. PORT RTF ISSUE References: Michi Henning wrote: [...] > We now have two identical repository IDs that denote different types, even > though each IDL specification uses different prefixes. I'd just like to emphasize that, from an interoperability perspective, and I think from the CORBA 2.0 IFR Submitter's perspective (I was there), identical RepositoryIds imply the same type. Everything else - the scoped names, modules, etc., are local to either the client or the server and are irrelevant. The CORBA 2.0 IFR submitters attempted to support situations where IDL would be localized - moved to different modules or even translated to a local language. This is why RepositoryIds rather than scoped names were made the definitive names for types. The CORBA 2.0 interop specification supports some of this by using RepositoryIds on the wire to identify types, but didn't go as far as allowing operation or attribute names to be localized. Client and server must agree on the spelling of operation names on the wire. The localizability of scoped names is one of the considerations that led to the situation where names in TypeCodes are not dependable. Some ORBs might leave them out for efficiency reasons, but different IFRs or localized versions of the IDL may actually use different names for the same thing. [...] > Question: What about other "nasty" characters inside prefixes? For example, > non-printing characters or spaces? Given that all of the repository ID, > except for the prefix, is composed from a limited character set, shouldn't > prefixes be limited to some sensible character set as well? Do we really > want to permit form feeds, newlines, tabs, ASCII BEL, etc in prefixes? > I thought we were now agreeing that the prefixes are not distinguishable from the rest once IDL (and its pragmas) have been parsed and the RepositoryIds generated. Also, I see that the there are restrictions on the characters after the prefix in IDL format RepositoryIds, and restrictions on the characters in DCE format RepositoryIds, but I don't see any restrictions at all for local format RepositoryIds in CORBA 2.2. If the consensus was that limiting the character set was important, I'd argue it should apply uniformly to all formats of RepositoryIds. -Bob > Cheers, > > > Michi. > -- > Michi Henning +61 7 33654310 > DSTC Pty Ltd +61 7 33654311 (fax) > University of Qld 4072 michi@dstc.edu.au > AUSTRALIA > http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 30 Apr 1998 07:13:58 +1000 (EST) From: Michi Henning To: Bob Kukura cc: port-rtf@omg.org Subject: Re: issue1241. PORT RTF ISSUE On Wed, 29 Apr 1998, Bob Kukura wrote: > Michi Henning wrote: > > [...] > > > We now have two identical repository IDs that denote different > types, even > > though each IDL specification uses different prefixes. > > I'd just like to emphasize that, from an interoperability > perspective, > and I think from the CORBA 2.0 IFR Submitter's perspective (I was > there), identical RepositoryIds imply the same type. Exactly. The example I showed demonstrates that different prefixes do not necessarily guarantee that repository IDs are unique (but I admit that the example is pathological). > Everything else - > the scoped names, modules, etc., are local to either the client or > the > server and are irrelevant. The CORBA 2.0 IFR submitters attempted > to > support situations where IDL would be localized - moved to different > modules or even translated to a local language. This is why > RepositoryIds rather than scoped names were made the definitive > names > for types. Personally, I don't think localization of things like module or operation names is a good idea. These names serve as keys to the underlying type in programming languages. In other words, a scoped name A::B::C is a key used to name a programming language object. Keys are never localized, simply because that prevents exchanging them between different locales. For example, if we have an IDL that is "localized" this way into Japanese, and then the Japanese client wants to talk to a French server, this would only work if the server knew the Japanese locale. Clearly, that makes life difficult for a server if it is being contaced by clients from 100 differnet locales... > The CORBA 2.0 interop specification supports some of this by using > RepositoryIds on the wire to identify types, but didn't go as far as > allowing operation or attribute names to be localized. Client and > server must agree on the spelling of operation names on the wire. Yes, and I think that is exactly how it should be. > The localizability of scoped names is one of the considerations that led > to the situation where names in TypeCodes are not dependable. Some ORBs > might leave them out for efficiency reasons, but different IFRs or > localized versions of the IDL may actually use different names for the > same thing. The optionality of names inside type codes creates a lot of problems. For example, type equivalence in CORBA is ill-defined partly for that reason. Also, for things like the Notification Service, the optionality of names inside type codes makes it quite hard to come up with a comprehensible and reliable filtering language. As far as I am concerned, names should be mandatory inside type codes... > > Question: What about other "nasty" characters inside prefixes? For example, > > non-printing characters or spaces? Given that all of the repository ID, > > except for the prefix, is composed from a limited character set, shouldn't > > prefixes be limited to some sensible character set as well? Do we really > > want to permit form feeds, newlines, tabs, ASCII BEL, etc in prefixes? > > > > I thought we were now agreeing that the prefixes are not distinguishable > from the rest once IDL (and its pragmas) have been parsed and the > RepositoryIds generated. We are agreeing. The reason I'm asking about "nasty" characters is purely pragmatic. For example, how many ORBs in existence will cope correctly with repository IDs that contain space, backspace, BEL, or a character in the range 0x80 - 0xff? Not many, I suspect. Given that IDL identifiers can only be composed of [a-z], [A-Z], [0-9] and underscore, we might as well have similar restrictions on the prefix. And no, there is no need to remind me that IDL identifiers *can* contain characters in the range 0x80 - 0xff ;-) This is still broken, and always will be, because we have no language bindings for such identifiers. > Also, I see that the there are restrictions on the characters after the > prefix in IDL format RepositoryIds, and restrictions on the characters > in DCE format RepositoryIds, but I don't see any restrictions at all for > local format RepositoryIds in CORBA 2.2. If the consensus was that > limiting the character set was important, I'd argue it should apply > uniformly to all formats of RepositoryIds. I would support that argument. Is it really important to be able to have a form feed in LOCAL repository id? Probably not... Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Wed, 24 Jun 1998 22:55:18 -0700 From: Jonathan Biggar To: orb_revision@omg.org, michi@dstc.edu.au Subject: Found this issue while looking in port-rtf, belongs in orb core RTF Issue #1241 from Michi. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 25 Jun 1998 16:10:33 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org Subject: Re: Found this issue while looking in port-rtf, belongs in orb core RTF On Wed, 24 Jun 1998, Jonathan Biggar wrote: > Issue #1241 from Michi. Thanks Jon. We should close that one without change. Bob Kukura argued convincingly that there is no need to restrict the characters that may appear inside a prefix (acutally, he didn't argue convincingly, but he's bigger than me :-). Of course, what exact characters can appear is (yet again) subject to preprocessor limitations. Also, how would you put a literal " into a prefix? Not that I care -- I don't think it's important. So, I would ignore the issue and close with no change. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html