Issue 5904: 2.3.1 The EventChannel Interface (event-rtf) Source: Connox (Mr. Raf Schietekat, raf_schietekat(at)ieee.org) Nature: Clarification Severity: Critical Summary: The first issue is whether one EventChannel has at most one or more ConsumerAdmin objects (and similarly for both Typed... and Supplier..., orthogonally). On the one hand, the specification says things like "Destruction of a ConsumerAdmin or SupplierAdmin object causes the implementation to invoke the disconnect operation on all proxies that were created via that ConsumerAdmin or SupplierAdmin object." (same section, previous page), on the other it says something like this conflicting "In such a case, the creator would simply export *the* ConsumerAdmin object." (my *emphasis*). Also, the only time a ConsumerAdmin is destroyed is when its EventChannel is destroyed, because only the EventChannel has a destroy-like operation, so there might as well be at most one ConsumerAdmin. The specification should therefore be more explicit about cardinality (and perhaps replace or back up the potato diagrams with UML ones). My current bet is that there is at most one of each ...Admin, and that the Proxy... objects are owned directly by the EventChannel (I went that way before I spotted the discrepancy): is that correct? I need to know because I am implementing (not just using) an Event Service as part of RayORB, and, other than verifying interoperability with Java, I am trying to make this a clean-room implementation, from the specifications only. I may also look at the Notification Service Specification, but this specification should be self-contained. I have grouped some errors below that require no clarification, because their appropriate correction is clear. There is a typing error "ProsyPushSupplier" in "2.3.7 The ProxyPushSupplier Interface", ironically two lines below the word "TypeError". There is an IDL error in "2.7 The CosTypedEventChannelAdmin Module": "ProxyPullConsumer obtain_typed_pull_consumer" must be corrected to "CosEventChannelAdmin::ProxyPullConsumer obtain_typed_pull_consumer" for successful compilation, and likewise "ProxyPushSupplier obtain_typed_push_supplier" must become "CosEventChannelAdmin::ProxyPushSupplier obtain_typed_push_supplier". In Appendix B, the example uses ...Ref, which, as far back as CORBA 2.2 (the first version I've worked with), is deprecated for C++. Unless I'm mistaken, the use of an environment is only required for C++ compilers that do not support exceptions (are there any left?), and is more distracting than educational. Please update to agree with the current mapping specification. Resolution: Revised Text: Actions taken: March 16, 2003: received issue Discussion: End of Annotations:===== From: webmaster@omg.org Date: 16 Mar 2003 02:49:02 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Raf Schietekat Company: Connox N.V. mailFrom: Raf_Schietekat@ieee.org Notification: Yes Specification: Event Service Specification Section: 2.3.1 The EventChannel Interface FormalNumber: 01-03-01.pdf Version: Version 1 . 1 RevisionDate: March 2001 Page: 2-10 Nature: Clarification Severity: Critical HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 Description The first issue is whether one EventChannel has at most one or more ConsumerAdmin objects (and similarly for both Typed... and Supplier..., orthogonally). On the one hand, the specification says things like "Destruction of a ConsumerAdmin or SupplierAdmin object causes the implementation to invoke the disconnect operation on all proxies that were created via that ConsumerAdmin or SupplierAdmin object." (same section, previous page), on the other it says something like this conflicting "In such a case, the creator would simply export *the* ConsumerAdmin object." (my *emphasis*). Also, the only time a ConsumerAdmin is destroyed is when its EventChannel is destroyed, because only the EventChannel has a destroy-like operation, so there might as well be at most one ConsumerAdmin. The specification should therefore be more explicit about cardinality (and perhaps replace or back up the potato diagrams with UML ones). My current bet is that there is at most one of each ...Admin, and that the Proxy... objects are owned directly by the EventChannel (I went that way before I spotted the discrepancy): is that correct? I need to know because I am implementing (not just using) an Event Service as part of RayORB, and, other than verifying interoperability with Java, I am trying to make this a clean-room implementation, from the specifications only. I may also look at the Notification Service Specification, but this specification should be self-contained. I have grouped some errors below that require no clarification, because their appropriate correction is clear. There is a typing error "ProsyPushSupplier" in "2.3.7 The ProxyPushSupplier Interface", ironically two lines below the word "TypeError". There is an IDL error in "2.7 The CosTypedEventChannelAdmin Module": "ProxyPullConsumer obtain_typed_pull_consumer" must be corrected to "CosEventChannelAdmin::ProxyPullConsumer obtain_typed_pull_consumer" for successful compilation, and likewise "ProxyPushSupplier obtain_typed_push_supplier" must become "CosEventChannelAdmin::ProxyPushSupplier obtain_typed_push_supplier". In Appendix B, the example uses ...Ref, which, as far back as CORBA 2.2 (the first version I've worked with), is deprecated for C++. Unless I'm mistaken, the use of an environment is only required for C++ compilers that do not support exceptions (are there any left?), and is more distracting than educational. Please update to agree with the current mapping specification.