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

[Michael Freedman <Michael.Freedman@oracle.com>]

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.   
    -Mike-

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