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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-coord message

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

Subject: Re: [wsrp-coord] Use properties to expose transient state?

I don't understand why this distinction is necessary.  We seem to have two use case:
     1) The consumer manages/renders the customization screens that allow users to change a portlets persistent state.
     2) Actors [usually portlets and/or the consumer itself] wish to receive state [changes] not only from end users but also from other actors [portlets] running in the environment.  In this situation I expect the portlet receiving state to have the responsibility of storing/maintaining that state for its use vs. keeping a reference to the state so it can request it later from the actor that utlimately has the state.  Because of this whether the state I receive is persistent, transient, or whatever shouldn't matter.  

I don't think we should support the use case of having the consumer opaquely maintain the portlets transient state above and beyond what is already defined in the spec.  Navigational state + sessionId/cookie support is good enough.

So, in the end, as I suggested in my e-mail yesterday we likely need to describe separately the data that pertains to use case 1 vs use case 2.  However the scope of this state isn't important.  

Rich Thompson wrote:

Q: Do we want to expand the current property concept to include published transient state?

[RDT] I think this would be the simplest model for developers. State is all stored in properties, what varies is the lifetime of that state. What we have now is "persistent state" and therefore survives application cycles, etc. Transient state should have a lifetime similar to that of a session.

A side-effect of the decision to support Consumer generated UIs for customizing persistent state is the need to distinguish between persistent and transient properties. The subcommittee last working on this proposed organizing the properties into models, each of which could then indicate the lifetime of the model. Comments? Other proposals?

Rich Thompson

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