[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] cloneBeforeWrite for CCP
Rich has it right. We alrady had this discussion about valid cloneBeforeWrite handling. I think the protocol is strict enough here. By setting the flag, the Consumer prohibts the Producer to write on the CCP, any therefor must do a clone first. It's perfectly legal and for the Producer to not to clone immediatly but rather do it before a write attempt occurs, i.e. as long as there is no need to make a copy, leave things as is. With this handling you can perfectly implement your CCP sharing scenario, I don't see a need for furhter restrictions in the protocol. Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development WSRP Standardization Technical Lead Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com Rich Thompson <richt2@us.ibm.co m> To wsrp-interop@lists.oasis-open.org 08/25/2004 12:36 cc AM Subject Re: [wsrp-interop] cloneBeforeWrite for CCP The difference between 2 and 3 is whether the Producer will immediately produce a clone when it is instructed that this user is not allowed to update the portlet's configuration. I am quite sure we do not want to encourage Producer's to do 2 as this will dramatically increase the number of clones. The 3rd choice produces a clone if and only if one is needed. The 1st choice is just the Producer saying it is unable to do such control on cloning and therefore faults to the Consumer to manage the producing of the clone. Rich Subbu Allamaraju <subbu@bea.com> 08/24/2004 05:31 PM To wsrp-interop@lists.oasis-o pen.org cc Subject Re: [wsrp-interop] cloneBeforeWrite for CCP This leaves one question open. With choices (1) and (3), what happens if the Consumer is sharing a CCP for multiple users, and would like to instruct the Producer to clone the CCP before making state changes? Any reason why we can't require a stricter interpretation of cloneBeforeWrite (an is option (2) below)? Subbu Rich Thompson wrote: > > The answer from the spec is that the Consumer is telling the Producer > that the user does not have permission to change the portlet's > configuration and that if such changes are required, a clone is allowed > and must be generated before the changes are applied. The Producer has > three basic choices (due to implementation differences); 1) Throw a > fault and force an explicit clone, 2) immediately clone (when > configuration changes are not later protected) and 3) intercept > configuration updates and clone only on the first one that occurs. > > Rich > > > *Subbu Allamaraju <subbu@bea.com>* > > 08/24/2004 09:42 AM > > > To > wsrp-interop@lists.oasis-open.org > cc > > Subject > [wsrp-interop] cloneBeforeWrite for CCP > > > > > > > > > > In response to a diagram in Primer, Andre sent this comment. I'm posting > to the interop group for further discussion. > > Regards, > > Subbu > > > Thinking about the case when a consumer sets "cloneBeforeWrite" on a > > CCP (the deleted performBlockingInteraction()). Should the producer > > throw a fault? Allow the Write? Do a second clone? I believe our > > producer just forces a clone to happen which is what the original > > diagram suggested! > > > > Maybe something to raise & discuss in the next interop call? > > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php . > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]