OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrp-interop] Consumer Persistent State Clarification

Thanks for the information. 
You mentioned that, "the choice to have Producers manage the state for their portlets maximizes the interoperability between implementations making different technology choices".  Can you clarify this statement, perhaps by providing an example of a situation in which Consumer side state persistence would lead to interoperability problems?
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Thursday, April 08, 2004 6:01 AM
To: wsrp-interop@lists.oasis-open.org
Subject: Re: [wsrp-interop] Consumer Persistent State Clarification

PortletHandles are cloned/managed by the Producer and there is a one-to-one correspondence between portletHandles and the associated portletState regardless of whether that state is stored on the Producer or Consumer. Therefore for your examples:

1. The Consumer can have two instances of the same portletHandle on a page, but as soon as they are allowed to have separate persistent state the handles become unique.

2. This case presumes persistent state managed by the Consumer while the spec has this managed by the Producer with the option of pushing it to the Consumer for storage. The "normal" case that the TC has discussed is users sharing a portletHandle until there is unique persistent state associated with the user. The cloneBeforeWrite setting is expected to be used when users share a portletHandle in this manner such that the Producer will do a clone while processing a user interaction if that processing requires a change to the portlet's persistent state.

Note that the choice to have Producers manage the state for their portlets maximizes the interoperability between implementations making different technology choices. Also, I'm not sure we have seen a Producer in the interop testing that has pushed the portletState to the Consumer ...


"Goldstein, Scott" <Scott.Goldstein@vignette.com>

04/07/2004 03:15 AM

[wsrp-interop] Consumer Persistent State Clarification

In section 6.1.3, it states the following:
"If the portletState field has a value, the Consumer MUST return this value on subsequent calls using the same portletHandle."
Does this mean that either of the following are not acceptable?
1.  The Consumer portal creates two portlets, A and B, and places them on a page.  Both of these portlets map to a single CCP on the producer.  The consumer persists separate opaque state for each portlet, but associates the state with the same portlet handle allowing use of the same CCP.  
2.  The Consumer portal creates a portlet and associates it with a single CCP.  For each user in the system, the Consumer persists seperate opaque state associated with the portlet.  Therefore, for each user, when making calls to the producer, the same portlet handle is used, but with different opaque state.
Essentially, the question comes down cloning expectations.  Is it completely up to the Consumer when a wsrp portlet is cloned and, therefore, making it legal to send different portlet state with a particular portel handle, or, is the Consumer required to request a clone every time it needs to persist different state for the same portlet?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]