[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?
I see your point. But once the consumer encounters binary state during its usage of a producer, it can stop using the producer/portlet (hopefully after immediate cleanup). Subbu Richard Jacob wrote: > no, I guess this wouldn't work. > The assumption you make is that on the first invocation the Producer pushes > the state, be it registration or creating a clone. > But couldn't the push happen at a later time? > I guess it can. Since for example the portlet might have state persistet at > a later time than at the time clone() was invoced. > Assume Consumer makeing a clone(), then interact. Then at some point in > time hit edit mode and modify persistent state. > So if you share between the cloning and the state change, the scenario is > not implementable. > > 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:richard.jacob@de.ibm.com > > > > Subbu Allamaraju > <subbu@bea.com> > To > 01/12/06 05:05 PM wsrp-interfaces@lists.oasis-open.or > g > cc > > Subject > Re: [wsrp-interfaces] Should > portlets/producers indicate that > they push 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:richard.jacob@de.ibm.com >> >> >> > >> Subbu Allamaraju > >> <subbu@bea.com> > > To >> 01/12/06 04:24 PM > wsrp-interfaces@lists.oasis-open.or >> 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:richard.jacob@de.ibm.com >>> >> >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]