Issue 1086:  How to deal with object identity (orb_revision)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: I"m not quite sure where this should go, but there should be an explicit
 statement somewhere in the CORBA descriptions that states how to deal
 with object identity with respect to subscribe/unsubscribe schemes.
 
 The (language/CORBA/etc independent) pattern
     interface SomeSender {
         void addSomeListener( in SomeListener theListener );
         void removeSomeListener( in SomeListener theListener );
         ...
     }
 is very commonly found, and as far as I understand it (I might be wrong,
 but if so, it needs to be documented that this would be incorrect),
 SomeListener actually needs to implement a "is_identical( Object )"
 operation that would be called by the removeSomeListener() operation
 in order to find out which of the registered listeners should be removed.
 

Resolution: 
Revised Text: 
Actions taken:
March 20, 1998: received issue
February 23, 1999: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <ernst@isi.com>
Date: Thu, 19 Mar 1998 14:51:18 -0800
X-Sender: ernst@postal.isi.com
To: issues@omg.org
From: Johannes Ernst <ernst@isi.com>
Subject: Clarification

I'm not quite sure where this should go, but there should be an
explicit
statement somewhere in the CORBA descriptions that states how to deal
with object identity with respect to subscribe/unsubscribe schemes.

The (language/CORBA/etc independent) pattern
    interface SomeSender {
        void addSomeListener( in SomeListener theListener );
        void removeSomeListener( in SomeListener theListener );
        ...
    }
is very commonly found, and as far as I understand it (I might be
wrong,
but if so, it needs to be documented that this would be incorrect),
SomeListener actually needs to implement a "is_identical( Object )"
operation that would be called by the removeSomeListener() operation
in order to find out which of the registered listeners should be
removed.

Also, if I'm right, it should be documented how to correctly implement
this pattern in a CORBA context.

Thanks,


Johannes Ernst
Intergrated Systems Inc.


Return-Path: <michi@dstc.edu.au>
X-Authentication-Warning: tigger.dstc.edu.au: michi owned process
doing -bs
Date: Fri, 20 Mar 1998 10:25:41 +1000 (EST)
From: Michi Henning <michi@dstc.edu.au>
To: Johannes Ernst <ernst@isi.com>
cc: issues@omg.org
Subject: Re: Clarification

On Thu, 19 Mar 1998, Johannes Ernst wrote:

> I'm not quite sure where this should go, but there should be an
explicit
> statement somewhere in the CORBA descriptions that states how to
deal
> with object identity with respect to subscribe/unsubscribe schemes.
> 
> The (language/CORBA/etc independent) pattern
>     interface SomeSender {
>         void addSomeListener( in SomeListener theListener );
>         void removeSomeListener( in SomeListener theListener );
>         ...
>     }
> is very commonly found, and as far as I understand it (I might be
wrong,
> but if so, it needs to be documented that this would be incorrect),
> SomeListener actually needs to implement a "is_identical( Object )"
> operation that would be called by the removeSomeListener() operation
> in order to find out which of the registered listeners should be
removed.

The semantics of CORBA::Obejct::is_equivalent() are well-understood.
If they are insufficient for your application (they may well be), it
is
trivial to add whatever identifier is appropriate to get the required
identity:

     typedef someType idType;

     interface SomeSender {
         idType addSomeListener(in SomeListener theListener);
         void removeSomeListener(in idType id);
     };

> Also, if I'm right, it should be documented how to correctly
implement
> this pattern in a CORBA context.

I don't think this belongs in the spec because the spec isn't into
making design recommendations.

The spec certainly cannot say how to correctly *implement* this. The
spec
very deliberately avoids talking about specification. Besides, how
to correctly implement this depends on application semantics, the
number
of listeners and senders, whether objects are transient or persistent,
and lot of other things. The spec can't talk about those.

							Cheers,

								Michi.
--
Michi Henning              +61 7 33654310
DSTC Pty Ltd               +61 7 33654311 (fax)
University of Qld 4072     michi@dstc.edu.au
AUSTRALIA
http://www.dstc.edu.au/BDU/staff/michi-henning.html