[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] Should portlets/producers indicate that theypush out persistent state?
Richard Jacob wrote: > why would it impose new rules? > It's just a hint for the Consumer whether it has to deal with it or not, if > it can't it can simply avoid to use such a portlet. I agree. Let's look at what's possible today. For registration state, the consumer would know at registration time if the producer returns state. If so, it can simply deregister immediately and avoid using it. For portlet state, if the consumer can't deal with state, it can drop the CCP handle/state, and continue to use the POP handle with readOnly flag (to prevent future clones). > I don't think that your conclusion is right that if the consumer can deal > with sharing the handles it automatically can share the state. > Think of the migraton scenario as an example: you copy the consumer from > one machine to another so the new machine has all handles available but of > course has no synch between the two in any way. My argument is that it is possible to implement a consumer that can share the handles and state without such a hint. A consumer dealing with both 1.0 and 2.0 producers (assuming that we add such a flag in 2.0) will have to design for such a sync anyway. Subbu > > Mit freundlichen Gruessen / best regards, > > Richard Jacob > ______________________________________________________ > IBM Lab Boeblingen, Germany > Dept.8288, WebSphere Portal Server Development > WSRP Team Lead & Technical Lead > WSRP Standardization > Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 > Email: mailto:firstname.lastname@example.org > > > > Subbu Allamaraju > <email@example.com> > To > 01/12/06 04:24 PM firstname.lastname@example.org > g > cc > > Subject > Re: [wsrp-interfaces] Should > portlets/producers indicate that > they push out persistent state? > > > > > > > > > > > I see the use cases, but I wonder if a consumer supporting both WSRP 1.0 > and 2.0 can count on using such a flag. > > Secondly, from a specification point of view, such a flag would impose > new rules on producers counting on pushing state to consumers as and > when required. > > You mentioned sharing handles below. If a consumer is able to share > handles (including cloned portletHandles) across different instances, it > can share the state as well. > > Subbu > > Richard Jacob wrote: >> I have a question regarding persistent state pushing to the Consumer. >> This can either be the state in the RegistrationContext or in the >> PortletContext. >> Currently the Producer can push its state whenever it likes to, and the >> Consumer requires to handle it accordingly (return it back, persist it). >> >> Shouldn't we have metadate that indicates the Producer/Portlets > preference >> to push out state? >> In that case the Consumer can choose to not use such a portlet. >> I see two use cases for it: >> 1.) the Consumer can't/doesn't want to persist the data be it for >> technical/resource reasons or legal/privacy reasons >> 2.) the Consumer "shares" the handles with another Consumer/Machine. We >> discussed such scenarios when we discussed import/export. >> From the Producer's perspective this is still the same Consumer (unless >> some security mechanism says otherwise), so protocol-wise this is > perfectly >> legal. >> However if the Producer chooses to push out persistent state, such >> scenarios won't work unless the different "Consumers" sync themselves in >> some manner. >> >> So what I'm asking for is basically two things: >> 1.) add metadata to the ServiceDesc saying that the registrationContext >> might contain state >> 2.) add metadata to the PortletDesc saying that the portlet intends to > push >> out state in the PortletContext >> >> Mit freundlichen Gruessen / best regards, >> >> Richard Jacob >> ______________________________________________________ >> IBM Lab Boeblingen, Germany >> Dept.8288, WebSphere Portal Server Development >> WSRP Team Lead & Technical Lead >> WSRP Standardization >> Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 >> Email: mailto:email@example.com >> > > > >