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