RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles

[Andre Kramer <andre.kramer@eu.citrix.com>]

Should cloneEntity not take an entityHandle rather than a refHandle? (Which
was one of the questions I returned for the 0.7 spec as I saw no need to
clone sessions/runtime-instances).

-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: 09 October 2002 18:47
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] [I#106] Uniqueness of entityHandles


I believe that
   (a) entity handles MUST be unique -- I.e. an entity handle MUST only
refer to a single persistent state.
   (b) cloneEntity MUST be able to return an identical entity handle.

I believe (b) not for the reasons currently discussed -- for if these were
the only arguments I would agree with Rich that this is better represented
as an error condition.  Rather, I come to (b) reluctantly as a consequence
of our [ill-fated?] decision to merge entity handles and session handles
into refHandles.  In doing so, the point of cloneEntity is no longer just to
clone the persistent state of the entity.  cloneEntity also clones the
runtime/session state.  In a world where it seems perfectly reasonable to
expect immutable entities that have runtime state, cloneEntity MUST be
capable
of returning the same entityHandle but a new/cloned refHandle for those
consumers wanting to preserve the runtime state on copy.

This leads to a further ugly observation that cloneEntity logically no
longer belongs in the optional Entity factor but rather in the required core
factor.  I.e. since refHandles aren't immutable and they come into existence
in our core factor they should be clonable in the core factor (ala Gils
observation for releaseRefHandle).

For me this is getting clumsy and confusing.  We may want to rethink our
approach to refHandles.
    -Mike-


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>