Issue 4204: CCM : Session2Context naming (components-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Is there any reason to name the context interface for extended session components as Session2Context in module Components::Extended? Why not simply SessionContext like in the Basic module? Resolution: see below Revised Text: In ptc/99-10-04, section 62.3, page 62-137, change the paragraph “Unless otherwise indicated, all of these interfaces are defined within the Basic module embedded within the Components module.” to read “Unless otherwise indicated, all of these interfaces are defined in the Components module.” In ptc/99-10-04, section 62.4, page 62-148, change the sentence “Unless otherwise indicated, all of these interfaces are defined within the Extended module embedded within the Components module.” to read “Unless otherwise indicated, all of these interfaces are defined in the Components module.” Actions taken: February 16, 2001: received issue May 13, 2002: closed issue Discussion: The intent was to remove the nested Basic and Extended modules. However, references to the Basic and Extended modules have not been removed from the document. This needs to be done. End of Annotations:===== From: "Bertram Neubauer" To: Subject: CCM : Session2Context and Servants Date: Fri, 16 Feb 2001 16:55:52 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: *;Ke9( Organization: GMD Fokus X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Frank Pilhofer CC: Philippe.Merle@lifl.fr, components-ftf@omg.org Subject: Re: 2nd draft for Vote 8 References: <200111061714.SAA06048@karjala.lifl.fr> <20011107010038.D484@rose.fpx.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [M:!![gFe9]@\d9E9dd9 Hello Frank, I've some doubts about your solutions of some of the issues. 3651/3725 I believe that a homeExecutor needs something like a context interface. And the interface itself (e.g. EntityHome) needs some of the operations I described. How can the container interact with the HomeExecutor before the container will be going down for some reason. All entity components can save their state but how can a home achieve this without getting a reference to its PSS? Or for security reason it may needs to know the principal of say a locator operation. And if come to the answer that a home needs some operations and needs a context then you have to say why not to use category depended interfaces as it is done for components. Good job for 4137, thanks! issue 4203 A can admit that the convenience operation create() make sence with the restrictions you described in your resolutions. I'm not really convinced that we need this operation. But anyway for convenience we can leave it in there. I can not see why a component implementation (business code) needs to handle with ObjectIDs. I think we should remove these other operations. At least we have to apply the the same restrictions for these operations (i.e. the Repository ID). But again I can't see the need. issue 4204 I didn't remove the modules yet. I was waiting until the language mapping discussion is finished. But good advice to think of doing the text changes. I'm not sure whether I got you right. Do you propose to move the interfaces from basic and extended into the top level module components without reducing the shape and number of interfaces but only with respect to the ongoing languagemapping discussion? Tom Frank Pilhofer wrote: > > Philippe.Merle@lifl.fr wrote: > > > > For the five following issues 3651 - 3725 - 4203 - 4204 - 4574, > > I have received 2 different proposals: > > > > - first ones are available at > > http://www.lifl.fr/~merle/CCM/Vote8_Frank.doc > > http://www.lifl.fr/~merle/CCM/Vote8_Frank.ps > > > > - second ones are available at > > http://www.lifl.fr/~merle/CCM/Vote8_Tom.doc > > http://www.lifl.fr/~merle/CCM/Vote8_Tom.ps > > > > Well, if Frank, Bertram and I manage to finalize the draft that we > are shooting back and forth, I think that Tom's resolutions to the > above issues are obsolete, and that mine are more relevant with > respect to the language mapping that we're closing in on. > > Tom, do you concur? > > I have attached a new document with an updated resolution to 4204 > that essentially removes all references to the Components::Basic and > Components::Extended modules. (It seems that some inheritance relation- > ships wouldn't work if this is not done.) > > > > > Finally, I have not received any proposal for Issue 4137. > > > > The attached document contains a proposal for that also. This is not > really a components-specific issue, so I propose to remove the paragraph > that this issue references. We should take care to introduce this idea > (integrity of value types contained in anys) to the core. > > Frank > > -- > Frank Pilhofer ........................................... fp@fpx.de > A family vacation is when you go away with people you need to get > away from. - Alfred E. Neuman > > ------------------------------------------------------------------------ > Name: Vote 8 - Alcatel.pdf > Vote 8 - Alcatel.pdf Type: Portable Document Format (application/pdf) > Encoding: base64 > > Name: Vote 8 - Alcatel.doc > Vote 8 - Alcatel.doc Type: WINWORD File (application/msword) > Encoding: base64 -- ============================================================================= GMD - German National Research Center for Information Technology Fokus - Research Institute of Open Communication Systems Tom Ritter Room: 5005 GMD-FOKUS Phone: +49 30 34 63 - 7278 Kaiserin-Augusta-Allee 31 FAX: +49 30 34 63 - 8000 D-10589 Berlin E-mail: ritter@fokus.gmd.de Germany ============================================================================= Date: Wed, 7 Nov 2001 08:40:23 +0100 From: 520065607613-0001@t-online.de (Frank Pilhofer) To: Tom Ritter Cc: Philippe.Merle@lifl.fr, components-ftf@omg.org Subject: Re: 2nd draft for Vote 8 Message-ID: <20011107084023.A469@rose.fpx.de> Reply-To: Frank Pilhofer References: <200111061714.SAA06048@karjala.lifl.fr> <20011107010038.D484@rose.fpx.de> <3BE8D18F.7EB0696@fokus.gmd.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BE8D18F.7EB0696@fokus.gmd.de>; from ritter@fokus.gmd.de on Wed, Nov 07, 2001 at 07:15:43AM +0100 X-Sender: 520065607613-0001@t-dialin.net Content-Type: text/plain; charset=us-ascii X-UIDL: a > 3651/3725 > I believe that a homeExecutor needs something like a context interface. > What about adding a sentence in the language mapping that a home may optionally implement the SessionComponent or EntityComponent interface? That way, we can let the user decide. I don't really want to introduce a whole new set of interfaces here. > > issue 4203 > A can admit that the convenience operation create() make sence with >the > restrictions you described in your resolutions. I'm not really >convinced > that we need this operation. But anyway for convenience we can leave >it > in there. > I'm also not convinced that these operations are needed. But I didn't want to remove the complete interface without ever thinking about whether it might be sensible or not, and not just as a result of an easily answer- able issue. > > issue 4204 > I'm not sure whether I got you right. Do you propose to move the > interfaces from basic and extended into the top level module >components > without reducing the shape and number of interfaces but only with > respect to the ongoing languagemapping discussion? > That's right. The modules are flattened, and all of the contents of the Basic:: and Extended:: submodule are moved without any change to the Components:: module itself. The language mapping is independent of these interfaces anyway. And this issue, which just complains about the name of an interface, would have been a weak excuse to completely redesign these interfaces ... Frank -- Frank Pilhofer ........................................... fp@fpx.de The early bird gets the worm ... but look what happens to the early worm! - Alfred E. Neuman Date: Wed, 07 Nov 2001 09:26:45 +0100 From: Tom Ritter Organization: GMD Fokus X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Frank Pilhofer CC: Philippe.Merle@lifl.fr, components-ftf@omg.org Subject: Re: 2nd draft for Vote 8 References: <200111061714.SAA06048@karjala.lifl.fr> <20011107010038.D484@rose.fpx.de> <3BE8D18F.7EB0696@fokus.gmd.de> <20011107084023.A469@rose.fpx.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: JiN!!:a@e9 > Tom Ritter wrote: > > > > 3651/3725 > > I believe that a homeExecutor needs something like a context interface. > > > > What about adding a sentence in the language mapping that a home may > optionally implement the SessionComponent or EntityComponent interface? > That way, we can let the user decide. > > I don't really want to introduce a whole new set of interfaces here. This seems to be the compromise. It seems that noone else has an opinion on introducing these interfaces. But maybe we have to describe the semantics of the operations of these interfaces, if there were inherited by a HomeExecutor instead of a ComponentExecutor. (And we have to take care that we have to give an appropriate answer for that issue.) > > > > > issue 4203 > > A can admit that the convenience operation create() make sence with the > > restrictions you described in your resolutions. I'm not really convinced > > that we need this operation. But anyway for convenience we can leave it > > in there. > > > > I'm also not convinced that these operations are needed. But I didn't > want to remove the complete interface without ever thinking about whether > it might be sensible or not, and not just as a result of an easily answer- > able issue. It may be right that you never thought about these operations before. But I'm thinking about these operations since I began implementing CCM. So this is not a quick shot. I can't find a reason why using these operaions. And they are sematically not well defined. But we can add a clearer description as you did it for the create operation. But I strongly advocate to remove at least the two operations dealing with the ObjectIds. By removing semantically unclear operations, that are not needed we can come to your KISS principle. If anyone knows a reason for these operations, please stand up and tell me. ... But ok, to get a compromise we can leave it in. :-( > > > > > issue 4204 > > I'm not sure whether I got you right. Do you propose to move the > > interfaces from basic and extended into the top level module components > > without reducing the shape and number of interfaces but only with > > respect to the ongoing languagemapping discussion? > > > > That's right. The modules are flattened, and all of the contents of > the Basic:: and Extended:: submodule are moved without any change to > the Components:: module itself. > > The language mapping is independent of these interfaces anyway. Not really because the component has to implement these interfaces. But it is ok for me to move these interfaces to the top level module. Here again I stongly propose to adopt the HUs proposal of reducing the interfaces. (This should be in the way of your promoted KISS principle). Maybe HU and you can finally get a compromise on that. Even if this is not part of the language mapping issue. > > And this issue, which just complains about the name of an > interface, > would have been a weak excuse to completely redesign these > interfaces ... But the issue that ask for the sense of the Session2Context interface might be a reason to redesign the interface because of its nonsence. And if there is no distinction between SessionContext and Session2Context left then we don't need the two interfaces. Tom -- ============================================================================= GMD - German National Research Center for Information Technology Fokus - Research Institute of Open Communication Systems Tom Ritter Room: 5005 GMD-FOKUS Phone: +49 30 34 63 - 7278 Kaiserin-Augusta-Allee 31 FAX: +49 30 34 63 - 8000 D-10589 Berlin E-mail: ritter@fokus.gmd.de Germany =============================================================================