Issue 10598: The use of Full Services definitions in CORBA/e spec (corba-e-ftf) Source: Raytheon (Mr. Gerald Lee Bickle, Gerald.L.Bickle(at)raytheon.com) Nature: Uncategorized Issue Severity: Summary: Problem: Since CORBA/e is for embedded constrained systems, one should be using LW Services as a minimal compliant point this would still allow one to offer up a Full Services in its offering but the other way around would not be compliant. Suggested Change The suggested change is to use LW Services definitions for CORBA/e. Resolution: Revised Text: Actions taken: January 19, 2007: received issue Discussion: Consensus was not reached on this issue in time. End of Annotations:===== erver-Uuid: 7829E76E-BB9E-4995-8473-3C0929DF7DD1 Subject: CORBA/E Specification Issue Date: Fri, 19 Jan 2007 08:23:28 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: CORBA/E Specification Issue thread-index: Acc7zQG905xnQNkCT0yD7W7fv2AhEg== From: "Jerry Bickle" To: issues@omg.org cc: corba-e-ftf@omg.org, sbc@omg.org X-OriginalArrivalTime: 19 Jan 2007 13:23:59.0431 (UTC) FILETIME=[14108570:01C73BCD] X-WSS-ID: 69AE19FA0K02622060-02-01 Issue 1. The use of Full Services definitions in CORBA/e spec. Problem: Since CORBA/e is for embedded constrained systems, one should be using LW Services as a minimal compliant point this would still allow one to offer up a Full Services in its offering but the other way around would not be compliant. Suggested Change The suggested change is to use LW Services definitions for CORBA/e. X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Flag: NO X-Spam-Score: -4.355 X-Spam-Level: X-Spam-Status: No, score=-4.355 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.044, BAYES_00=-2.599] From: "Johnny Willemsen" To: "'Victor Giddings'" , Subject: RE: Straw Poll: issues 10598, 10599, 11416 Date: Thu, 7 Feb 2008 20:21:53 +0100 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acho+VmizX1a7tQUTTOrSePzmntZFgAxE6lw X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m17JNg3K029989 Hi, > 10598: Title: "The use of Full Services definitions in CORBA/e spec". The issue is whether the "Lightweight" version of the the Naming and Event Services should be the basis of services in the Compact Profile. The present spec has the "full" service as required. I see two alternatives: A) Close, No Change or B) adopt basically as specified. Please vote: [A, B, or propose a different solution]: JW: To my idea we should make the change, "lightweight" is the basis 10599: Title: "The removal of static any from micro". The proposal is to include type Any in Micro profile "as an optional compliance point that is not mandatory but is part of the profile". I see three alternatives: A) Close, No Change, B) adopt as specified, C) require type Any support in Micro profile. Please vote: [A, B, or C, or propose a different solution]: JW: This one is harder to answer. I do see that some environment would like to use the Any but on the other side the Any is huge. It could be made an optional compliance point if people think this is really usefull. Just for your info, TAO has Any in its micro profile, we haven't found time to refactor our code 11416: Title: "More wrong references in chapter 11". The issues with the reference numbering somewhat obscures whether create_reference_with_id belongs in CORBA/e Micro profile. I think we should discuss whether the "create_reference" operations are appropriate in either profile. I think it is clear that the ability to create a reference from other than an activated servant was mainly to support ServantManagers and default servants. While it is possible to use create_reference_with_id even with SYSTEM_ID policy, it could be considered unnecessary fluff that gums up the API. I think it is also reasonable to question whether we need these operation in Compact profile. I am more uncertain about the choices for resolving this issue, but lets try A) close, No Change, B) adopt as specified (remove create_reference_with_id from Micro profile), or C) remove create_reference and create_reference_with_id from both Compact and Micro. Please vote: [A, B, or C, or propose a different solution]: JT: I would at least go for removing create_reference_with_id from micro profile. I am not sure whether we should zap this from compact, you are right about the fact that servant manager/default servants are not part of compact also. We could remove it, but I wonder what others have to say.