[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Issue ???: producer induced entity state changes
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC