Issue 5905: meaning of "dispose(d)" throughout this specification. (event-rtf) Source: Connox (Mr. Raf Schietekat, raf_schietekat(at)ieee.org) Nature: Clarification Severity: Critical Summary: This is about the meaning of "dispose(d)" throughout this specification. "dispose" does not occur in all of CORBA 3.0 (02-06-01.pdf), so I have no clear idea of what it means. As a possible interpretation, it makes no sense that a reference would be *released*, as a result of calling an operation through it. It would make sense if a PushConsumer's PushSupplier object reference were released when the PushConsumer executes a disconnect_push_supplier(), but "2.1.1 The PushConsumer Interface" specifically says "The PushConsumer object reference is disposed.". I can accept that a proxy would be *destroyed* when it is disconnected, because it is dedicated to a specific event relationship, and implied destruction would be a convenience there, but, other than "Figure 2-6 State diagram of a proxy." in "2.2.5 Event Channel Administration" on p. 2-8, I see nothing to emphasise this as a difference with plain (non-proxy) end points. Yet, as I see it, plain end points may be long-lived objects, that may engage in several event-passing relationships during their lifetimes. There is no possibility for the "infinite recursive calls to these disconnect operations" that "2.1.5 Disconnection Behavior" mentions if the reference to the other side is simply released after sending it a disconnect; there is no need to destroy anything for that purpose, or faking OBJECT_NOT_EXIST. So why do I get the impression that the revision to the Event Service Specification wants those non-proxy end points to be destroyed as well, although not unequivocally? It all looks rather messy, especially the thing about the inappropriate OBJECT_NOT_EXIST. And yet, I need to know for certain, to ensure interoperability and portability (I am currently implementing an Event Service for RayORB, not just using one). And can I make a suggestion on the side: there should be a document comprising known errata and issues for every official document, to avoid duplicate reports. w3c.org seems to do a good job of helping itself that way. Resolution: Revised Text: Actions taken: March 16, 2003: received issue Discussion: End of Annotations:===== From: webmaster@omg.org Date: 16 Mar 2003 03:45:57 -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.1.* FormalNumber: 01-03-01.pdf Version: Version 1 . 1 RevisionDate: March 2001 Page: 2-2 trough 2-4 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 This is about the meaning of "dispose(d)" throughout this specification. "dispose" does not occur in all of CORBA 3.0 (02-06-01.pdf), so I have no clear idea of what it means. As a possible interpretation, it makes no sense that a reference would be *released*, as a result of calling an operation through it. It would make sense if a PushConsumer's PushSupplier object reference were released when the PushConsumer executes a disconnect_push_supplier(), but "2.1.1 The PushConsumer Interface" specifically says "The PushConsumer object reference is disposed.". I can accept that a proxy would be *destroyed* when it is disconnected, because it is dedicated to a specific event relationship, and implied destruction would be a convenience there, but, other than "Figure 2-6 State diagram of a proxy." in "2.2.5 Event Channel Administration" on p. 2-8, I see nothing to emphasise this as a difference with plain (non-proxy) end points. Yet, as I see it, plain end points may be long-lived objects, that may engage in several event-passing relationships during their lifetimes. There is no possibility for the "infinite recursive calls to these disconnect operations" that "2.1.5 Disconnection Behavior" mentions if the reference to the other side is simply released after sending it a disconnect; there is no need to destroy anything for that purpose, or faking OBJECT_NOT_EXIST. So why do I get the impression that the revision to the Event Service Specification wants those non-proxy end points to be destroyed as well, although not unequivocally? It all looks rather messy, especially the thing about the inappropriate OBJECT_NOT_EXIST. And yet, I need to know for certain, to ensure interoperability and portability (I am currently implementing an Event Service for RayORB, not just using one). And can I make a suggestion on the side: there should be a document comprising known errata and issues for every official document, to avoid duplicate reports. w3c.org seems to do a good job of helping itself that way.