Re: [wsrp-wsia] Issue ???: producer induced entity state changes

[Alejandro Abdelnur <alejandro.abdelnur@sun.com>]

Based on what was said this morning during the conf call and a quick 
scan to Mike's explanation I would be in favor of the 'clone' approach. 
This would allow producer implementations to hide the details of 
clonning from entities. Going specific, a JSR168 container could handle 
the without any special intervention by the portlet.

Alejandro

Michael Freedman wrote:
> Sorry, but we got on to this topic this morning without identifying its
> issue number.
> 
> This morning we discussed a potential modification to the 2 phased
> protocol described in the .7 draft supporting producer controlled entity
> state changes.  The current proposal has us passing a boolean to each
> operation where a producer might update entity state [currently only
> performInteraction].  The boolean is called entityStateChangeOK.  If
> true the producer can freely update an entity's state.  If false, the
> producer must not update the entity state.  Rather it throws a special
> fault which the consumer recognizes and decides on how to proceed.
> Typically, it is expected the consumer will clone the entity and then
> recall the original operation on the newly cloned entity. This handles
> the situation that the consumer understand/manages when new entities
> come into existence, however the producer has a need to update entity
> state.
> 
> In a side conversation with Rich, I had suggested the following
> modification to this scheme.  Expand the meaning of
> "entityStateChange".  Allow this field to carry one of three values:
> "OK", "Fault", or "Clone".  "OK" and "Fault" has the same semantics as
> the original proposal.  "Clone" means the producer MUST clone the entity
> prior to making any state change.  Upon return from the call the
> producer returns the new entity [and new refhandle] to the consumer who
> MUST update its state accordingly.
> 
> This morning it was pointed out that a simpler scheme could be
> sufficient.  This scheme removes the "Fault" situation in deference to
> "Clone".  I.e. The field would become "cloneEntityOnStateChange".  If
> the value is true, the producer MUST clone the entity before making any
> changes, otherwise it is free to change the entity state in any way it
> desires.
> 
> I had originally proposed the first scheme as I was worried there might
> be use cases where the consumer had to direct/control the clone
> operation.  I.e. we have talked about giving the consumer [some]
> latitude in supporting hierarchies/etc.  I wasn't sure whether in such
> situations a simple clone was sufficient.  Keeping the "Fault" case
> allowed a [back]door for these consumers.  If we choose to move to the
> simpler, no-fault, scheme folks need to make sure there isn't a need for
> anything other then a simple clone.
> 
> I will leave it to Rich to expand upon this.  Specifically, to describe
> the changes to the return value(s) from performInteraction.
> 
>     -Mike-
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>