Issue 10599: The removal of static any from micro (corba-e-ftf) Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com) Nature: Uncategorized Issue Severity: Summary: Problem: The use of static any may be needed in a micro profile. For example, SDR Deployment and Configuration which can be done for embedded constrained environments for signal processing environments such as DSP and RTL devices need this capability. Suggested Change Make the static any as an optional compliance point that is not mandatory but is part of the profile. Resolution: Revised Text: Actions taken: January 19, 2007: received issue Discussion: The profiles for CORBA/e were developed in order to cut down the confusion associated with the number of optional compliance points in the present specification. Therefore, the introduction of an option on a profile (which is already an option) is resisted. Inclusion of (static) Any in the Micro profile was also considered, and rejected because it would leave no profile without the option of removing support for type Any, a significant cost in footprint and complexity. Therefore, no changes were made. Disposition: Closed, no change 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 2: The removal of static any from micro Problem: The use of static any may be needed in a micro profile. For example, SDR Deployment and Configuration which can be done for embedded constrained environments for signal processing environments such as DSP and RTL devices need this capability. Suggested Change Make the static any as an optional compliance point that is not mandatory but is part of the profile. ------------------------------------------ Jerry Bickle Chief Scientist, SDR Products 6511 Constitution Drive Fort Wayne, IN 46804 1 260-436-7168 (Work) 1 260-436-6708 (Fax) 1 260-249-8162 (Mobile) www.prismtech.com 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.