Issue 3175: Notification service: admin MyChannel attribute (notif_service-rtf) Source: Micro Focus (Mr. Bjarne Rasmussen, nobodybrasmussen(at)silverstream.com) Nature: Uncategorized Issue Severity: Summary: The notification service administration objects support an attribute called MyChannel that returns the event channel that first created the administration object. The value type of this attribute is EventChannel. For typed administration objects, the typed channel can not be returned because a TypedEventChannel is not compatible with an EventChannel. One solution is to change the value type of this attribute to a generic Object, which can be narrowed to the correct type. Resolution: Revised Text: Actions taken: January 4, 2000: received issue Discussion: End of Annotations:===== Date: Mon, 03 Jan 2000 17:20:40 -0600 From: Bjarne Rasmussen Organization: PrismTech Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org Subject: Notification service: admin MyChannel attribute Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: GFb!!M]Z!!H! Organization: PrismTech Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: notif-service-rtf@omg.org CC: Paul Moxon , Steve Osselton Subject: Issue 3175 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @"5e9@40e9e?Yd9S+kd9 Hi, To resolve issue 3175, we suggest a minimum impact solution where the type of the MyChannel attribute is changed to CORBA::Object. It can then be narrowed to an EventChannel or TypedEventChannel object as appropriate. A more dramatic solution is to make CosTypedEventChannelAdmin::TypedEventChannel inherit from CosEventChannelAdmin::EventChannel. We would need to remove the destroy operation from CosTypedEventChannelAdmin::TypedEventChannel and rename the two operations to for_typed_consumers and for_typed_suppliers. In a similar manner, the CosTypedNotifyChannelAdmin::TypedEventChannel should inherit from both CosNotifyChannelAdmin::EventChannel and CosTypedEventChannelAdmin::TypedEventChannel. Again, we would need to put _typed into some of the operation names and attributes. This is perhaps the most logical solution because a typed channel should "be an" un-typed channel? Best regards, Bjarne. From: Andy Till To: "'Bjarne Rasmussen'" , notif-service-rtf@omg.org Cc: Paul Moxon , Steve Osselton Subject: RE: Issue 3175 Date: Thu, 16 Mar 2000 09:55:32 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 9hU!!afIe9_;\!!~*=!! Hi, Does anybody on this list know why TypedEventChannel did not inherit From EventChannel in the original events spec? Was it just an oversight, or was there some really good, but obscure, reason? Andy > -----Original Message----- > From: Bjarne Rasmussen [mailto:br@us.prismtechnologies.com] > Sent: Thursday, 16 March 2000 1:23 > To: notif-service-rtf@omg.org > Cc: Paul Moxon; Steve Osselton > Subject: Issue 3175 > > > Hi, > > To resolve issue 3175, we suggest a minimum impact solution where > the > type of the MyChannel attribute is changed to CORBA::Object. > It can then > be narrowed to an EventChannel or TypedEventChannel object as > appropriate. > > A more dramatic solution is to make > CosTypedEventChannelAdmin::TypedEventChannel inherit from > CosEventChannelAdmin::EventChannel. We would need to remove > the destroy > operation from CosTypedEventChannelAdmin::TypedEventChannel and > rename > the two operations to for_typed_consumers and > for_typed_suppliers. In a > similar manner, the > CosTypedNotifyChannelAdmin::TypedEventChannel should > inherit from both CosNotifyChannelAdmin::EventChannel and > CosTypedEventChannelAdmin::TypedEventChannel. Again, we would need > to > put _typed into some of the operation names and attributes. This is > perhaps the most logical solution because a typed channel > should "be an" > un-typed channel? > > Best regards, > Bjarne. > > X-Sender: mjg@necsyl01.nectech.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 16 Mar 2000 17:53:03 -0500 To: Andy Till From: "Michael J. Greenberg" Subject: RE: Issue 3175 Cc: "'Bjarne Rasmussen'" , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: i/B!!1Djd9VU9!!c6'e9 Hi Andy, The reason is that this inheritance would cause an illegal IDL inheritance conflict. The problem is that the CosTypedEventChannelAdmin::TypedEventChannel interface defines operations called "for_consumers" and "for_suppliers" that return interface of types TypedConsumerAdmin and TypedSupplierAdmin, respectively. And, the CosEventChannelAdmin::EventChannel interface defines operations called "for_consumers" and "for_suppliers" that return interfaces of type ConsumerAdmin and SupplierAdmin, respectively. It is illegal for one IDL interface to inherit from another IDL interface that defines operations of the same name yet return different types (or have different parameter signatures in general). In this case, if the inheritance you propose existed, then TypedEventChannel would support two variations of both "for_consumers" and "for_suppliers", where each pair of like named operations would be defined to return two different data types. That being said, why the original authors of the Event Service did not name the operations defined in the TypedEventChannel interface "for_typed_consumers" and "for_typed_suppliers" is beyond me. This would have resolved the conflict, and enabled the inheritance you propose. Note that in the original OMG Notification Service spec, we did not recognize the existence of this conflict, and defined CosTypedNotifyChannelAdmin::TypedEventChannel to multiply inherit from CosNotifyChannelAdmin::EventChannel and CosTypedEventChannelAdmin::TypedEventChannel. But, since the former inherits from the CosEventChannelAdmin::EventChannel interface, the original OMG Notification Service IDL was actually illegal!!! This was recognized and resolved by the first Notification Service RTF. Removing this inheritance made the resulting CosTypedNOtifyChannelAdmin::TypedEventChannel interface much more complex. My preference was to simply modify the CosTypedEventChannelAdmin::TypedEventChannel interface the way I proposed in the previous paragraph, but this was rejected by many members of the RTF who felt it was not advisable to modify the IDL for a spec that had existed unchanged for so long (i.e., the Event Service), since this would invalidate existing implementations (as if there were existing implementations of the Typed Event Service!). I hope this helps! Regards, Mike At 09:55 AM 3/16/00 +0800, Andy Till wrote: >Hi, > >Does anybody on this list know why TypedEventChannel did not inherit From >EventChannel in the original events spec? Was it just an oversight, or was >there some really good, but obscure, reason? > >Andy > >> -----Original Message----- >> From: Bjarne Rasmussen [mailto:br@us.prismtechnologies.com] >> Sent: Thursday, 16 March 2000 1:23 >> To: notif-service-rtf@omg.org >> Cc: Paul Moxon; Steve Osselton >> Subject: Issue 3175 >> >> >> Hi, >> >> To resolve issue 3175, we suggest a minimum impact solution where the >> type of the MyChannel attribute is changed to CORBA::Object. >> It can then >> be narrowed to an EventChannel or TypedEventChannel object as >> appropriate. >> >> A more dramatic solution is to make >> CosTypedEventChannelAdmin::TypedEventChannel inherit from >> CosEventChannelAdmin::EventChannel. We would need to remove >> the destroy >> operation from CosTypedEventChannelAdmin::TypedEventChannel and rename >> the two operations to for_typed_consumers and >> for_typed_suppliers. In a >> similar manner, the >> CosTypedNotifyChannelAdmin::TypedEventChannel should >> inherit from both CosNotifyChannelAdmin::EventChannel and >> CosTypedEventChannelAdmin::TypedEventChannel. Again, we would need to >> put _typed into some of the operation names and attributes. This is >> perhaps the most logical solution because a typed channel >> should "be an" >> un-typed channel? >> >> Best regards, >> Bjarne. >> >> > > Michael J. Greenberg NEC Systems, Inc. 305 Foster Street Littleton, MA 01460-2004 VOX: (978)-742-8127 FAX: (978)-742-8557 E-mail: mjg@nectech.com From: Andy Till To: "Michael J. Greenberg (NEC)" Cc: "'Bjarne Rasmussen'" , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Subject: RE: Issue 3175 Date: Fri, 17 Mar 2000 08:57:34 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: EG4!!:/&e9gUWd9iHm!! Thanks Mike. I realised the change required in the IDL, but as you said, cannot figure out why it was not done that way in the first place. As to not changing it because it has been around a long time, I'm not persuaded on that one. I found the lack of inheritance a pain several times because of things I wanted to do in use and implementation of event services. Others have probably felt the same. We can make a small change to Notification now, but how long before the issue comes up again? There are only so many small sticking plasters you can apply before you need a real bandage. I'm not coming down on the side of definitely changing at this point (I'd need the nod from the poor buggers responsible for re-releasing OrbixTalk and OrbixEvents), but I think we should seriously consider the option so we can hear the negative arguments. Andy > -----Original Message----- > From: Michael J. Greenberg (NEC) > Sent: Friday, 17 March 2000 6:53 > To: Andy Till > Cc: 'Bjarne Rasmussen'; notif-service-rtf@omg.org; Paul Moxon; Steve > Osselton > Subject: RE: Issue 3175 > > > Hi Andy, > > The reason is that this inheritance would cause an illegal > IDL inheritance > conflict. The problem is that the > CosTypedEventChannelAdmin::TypedEventChannel > interface defines operations called "for_consumers" and > "for_suppliers" that > return interface of types TypedConsumerAdmin and TypedSupplierAdmin, > respectively. And, the CosEventChannelAdmin::EventChannel interface > defines operations called "for_consumers" and "for_suppliers" > that return > interfaces of type ConsumerAdmin and SupplierAdmin, respectively. It > is illegal for one IDL interface to inherit from another IDL > interface > that defines operations of the same name yet return different > types (or > have different parameter signatures in general). In this case, if > the > inheritance you propose existed, then TypedEventChannel would > support > two variations of both "for_consumers" and "for_suppliers", where > each > pair of like named operations would be defined to return two > different > data types. > > That being said, why the original authors of the Event Service did > not > name the operations defined in the TypedEventChannel interface > "for_typed_consumers" and "for_typed_suppliers" is beyond me. > This would > have resolved the conflict, and enabled the inheritance you propose. > > Note that in the original OMG Notification Service spec, we did not > recognize the existence of this conflict, and defined > CosTypedNotifyChannelAdmin::TypedEventChannel to multiply inherit > from > CosNotifyChannelAdmin::EventChannel and > CosTypedEventChannelAdmin::TypedEventChannel. But, since the former > inherits from the CosEventChannelAdmin::EventChannel interface, the > original OMG Notification Service IDL was actually illegal!!! This > was recognized and resolved by the first Notification Service RTF. > Removing this inheritance made the resulting > CosTypedNOtifyChannelAdmin::TypedEventChannel interface much more > complex. My preference was to simply modify the > CosTypedEventChannelAdmin::TypedEventChannel interface the way I > proposed in the previous paragraph, but this was rejected by many > members of the RTF who felt it was not advisable to modify the IDL > for a spec that had existed unchanged for so long (i.e., the > Event Service), since this would invalidate existing implementations > (as if there were existing implementations of the Typed Event > Service!). > > I hope this helps! > > Regards, > Mike > > At 09:55 AM 3/16/00 +0800, Andy Till wrote: > >Hi, > > > >Does anybody on this list know why TypedEventChannel did not > inherit From > >EventChannel in the original events spec? Was it just an > oversight, or was > >there some really good, but obscure, reason? > > > >Andy > > > >> -----Original Message----- > >> From: Bjarne Rasmussen [mailto:br@us.prismtechnologies.com] > >> Sent: Thursday, 16 March 2000 1:23 > >> To: notif-service-rtf@omg.org > >> Cc: Paul Moxon; Steve Osselton > >> Subject: Issue 3175 > >> > >> > >> Hi, > >> > >> To resolve issue 3175, we suggest a minimum impact > solution where the > >> type of the MyChannel attribute is changed to CORBA::Object. > >> It can then > >> be narrowed to an EventChannel or TypedEventChannel object as > >> appropriate. > >> > >> A more dramatic solution is to make > >> CosTypedEventChannelAdmin::TypedEventChannel inherit from > >> CosEventChannelAdmin::EventChannel. We would need to remove > >> the destroy > >> operation from > CosTypedEventChannelAdmin::TypedEventChannel and rename > >> the two operations to for_typed_consumers and > >> for_typed_suppliers. In a > >> similar manner, the > >> CosTypedNotifyChannelAdmin::TypedEventChannel should > >> inherit from both CosNotifyChannelAdmin::EventChannel and > >> CosTypedEventChannelAdmin::TypedEventChannel. Again, we > would need to > >> put _typed into some of the operation names and attributes. This > is > >> perhaps the most logical solution because a typed channel > >> should "be an" > >> un-typed channel? > >> > >> Best regards, > >> Bjarne. > >> > >> > > > > > Michael J. Greenberg > NEC Systems, Inc. > 305 Foster Street > Littleton, MA 01460-2004 > VOX: (978)-742-8127 > FAX: (978)-742-8557 > E-mail: mjg@nectech.com > From: Andy Till To: notif-service-rtf@omg.org Subject: Event Channel inheritance. Date: Mon, 27 Mar 2000 14:32:34 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 0PE!!~\T!!J73e9F/4!! A quick straw poll. What are the views of everybody else on this list with respect to fixing the root cause of notification issue 3175. This would mean changing the events & notification IDL to allow TypedEventChannel to inherit from EventChannel, rather than just patching the notification IDL again. Andy Date: Mon, 27 Mar 2000 22:13:01 +1000 (EST) From: Michi Henning To: Andy Till cc: notif-service-rtf@omg.org Subject: Re: Event Channel inheritance. In-Reply-To: <40CD287F6F20D311A74B00A0C9A0C51C0EEF3D@frac.iona.com.au> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: )R1e9leSd9h3]!!]A0e9 On Mon, 27 Mar 2000, Andy Till wrote: > A quick straw poll. > > What are the views of everybody else on this list with respect to > fixing the > root cause of notification issue 3175. This would mean changing the > events & > notification IDL to allow TypedEventChannel to inherit from > EventChannel, > rather than just patching the notification IDL again. I'd prefer to fix it properly, rather than doing a patch of some kind. Either way, it looks like a fix will require breaking existing code anyway... (Of course, we can choose not to fix it at all, too.) The versioning problem is what I'm concerned about. We'd probably have to version the module and change the tokens passed to resolve_initial_references, so the client can nominate the version. Cheers, Michi. X-Sender: mjg@necsyl01.nectech.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 27 Mar 2000 09:54:12 -0500 To: Andy Till From: "Michael J. Greenberg" Subject: Re: Event Channel inheritance. Cc: notif-service-rtf@omg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: lbe!!aD!"!A quick straw poll. > >What are the views of everybody else on this list with respect to fixing the >root cause of notification issue 3175. This would mean changing the events & >notification IDL to allow TypedEventChannel to inherit from EventChannel, >rather than just patching the notification IDL again. > >Andy > > > -- Michael J. Greenberg NEC Systems, Inc. 305 Foster Street Tel: (978)-742-8127 Littleton, MA 01460 Fax: (978)-742-8557 mjg@nectech.com From: dyc@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Michael J. Greenberg" cc: Andy Till , "'Bjarne Rasmussen'" , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Message-ID: <852568B2.005A213A.00@d54mta08.raleigh.ibm.com> Date: Thu, 30 Mar 2000 10:15:59 -0600 Subject: RE: Issue 3175 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: ~B*e91&Nd9YVS!!U;Ae9 Mike, Even we didn't implement the Typed Event Channel but I agree with you that we should fix the TypedEvent ChannelAdmin inheritance problem in the spec. Best Regards, David Chang WebSphere, Security Service Development IBM SWS Division, Internal Mail Stop 9640 Austin, Tx 78758 E-Mail:dyc@us.ibm.com Phone:(512)838-0559, T/L 678-0559 Fax: (512)838-1032 "Michael J. Greenberg" on 03/16/2000 04:53:03 PM To: Andy Till cc: "'Bjarne Rasmussen'" , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Subject: RE: Issue 3175 Hi Andy, The reason is that this inheritance would cause an illegal IDL inheritance conflict. The problem is that the CosTypedEventChannelAdmin::TypedEventChannel interface defines operations called "for_consumers" and "for_suppliers" that return interface of types TypedConsumerAdmin and TypedSupplierAdmin, respectively. And, the CosEventChannelAdmin::EventChannel interface defines operations called "for_consumers" and "for_suppliers" that return interfaces of type ConsumerAdmin and SupplierAdmin, respectively. It is illegal for one IDL interface to inherit from another IDL interface that defines operations of the same name yet return different types (or have different parameter signatures in general). In this case, if the inheritance you propose existed, then TypedEventChannel would support two variations of both "for_consumers" and "for_suppliers", where each pair of like named operations would be defined to return two different data types. That being said, why the original authors of the Event Service did not name the operations defined in the TypedEventChannel interface "for_typed_consumers" and "for_typed_suppliers" is beyond me. This would have resolved the conflict, and enabled the inheritance you propose. Note that in the original OMG Notification Service spec, we did not recognize the existence of this conflict, and defined CosTypedNotifyChannelAdmin::TypedEventChannel to multiply inherit from CosNotifyChannelAdmin::EventChannel and CosTypedEventChannelAdmin::TypedEventChannel. But, since the former inherits from the CosEventChannelAdmin::EventChannel interface, the original OMG Notification Service IDL was actually illegal!!! This was recognized and resolved by the first Notification Service RTF. Removing this inheritance made the resulting CosTypedNOtifyChannelAdmin::TypedEventChannel interface much more complex. My preference was to simply modify the CosTypedEventChannelAdmin::TypedEventChannel interface the way I proposed in the previous paragraph, but this was rejected by many members of the RTF who felt it was not advisable to modify the IDL for a spec that had existed unchanged for so long (i.e., the Event Service), since this would invalidate existing implementations (as if there were existing implementations of the Typed Event Service!). I hope this helps! Regards, Mike At 09:55 AM 3/16/00 +0800, Andy Till wrote: >Hi, > >Does anybody on this list know why TypedEventChannel did not inherit From >EventChannel in the original events spec? Was it just an oversight, or was >there some really good, but obscure, reason? > >Andy > >> -----Original Message----- >> From: Bjarne Rasmussen [mailto:br@us.prismtechnologies.com] >> Sent: Thursday, 16 March 2000 1:23 >> To: notif-service-rtf@omg.org >> Cc: Paul Moxon; Steve Osselton >> Subject: Issue 3175 >> >> >> Hi, >> >> To resolve issue 3175, we suggest a minimum impact solution where the >> type of the MyChannel attribute is changed to CORBA::Object. >> It can then >> be narrowed to an EventChannel or TypedEventChannel object as >> appropriate. >> >> A more dramatic solution is to make >> CosTypedEventChannelAdmin::TypedEventChannel inherit from >> CosEventChannelAdmin::EventChannel. We would need to remove >> the destroy >> operation from CosTypedEventChannelAdmin::TypedEventChannel and rename >> the two operations to for_typed_consumers and >> for_typed_suppliers. In a >> similar manner, the >> CosTypedNotifyChannelAdmin::TypedEventChannel should >> inherit from both CosNotifyChannelAdmin::EventChannel and >> CosTypedEventChannelAdmin::TypedEventChannel. Again, we would need to >> put _typed into some of the operation names and attributes. This is >> perhaps the most logical solution because a typed channel >> should "be an" >> un-typed channel? >> >> Best regards, >> Bjarne. >> >> > > Michael J. Greenberg NEC Systems, Inc. 305 Foster Street Littleton, MA 01460-2004 VOX: (978)-742-8127 FAX: (978)-742-8557 E-mail: mjg@nectech.com