Re: [wsrp-interfaces] Transient Properties

[Stefan Hepper <sthepper@hursley.ibm.com>]

Thanks for clearifying want I ment. I should have said 
wsrp:navigationalState explicitly.

Stefan

Rich Thompson wrote:
> 
> I understood Stefan to be saying the navState scope was useful for 
> cross-portlet sharing, but that he didn't see value for the 
> consumerRequest scope.
> 
> I think the issue he raises about consumerSession and 
> consumerApplication are related to keeping render urls idempotent. There 
> either needs to be a clean solution to this issue (btw, I don't have 
> one) or we need to seriously question whether we are pushing too much 
> into a single proposal.
> 
> Rich
> 
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 09/15/05 09:21 AM
> 
> 	
> To
> 	interfaces <wsrp-interfaces@lists.oasis-open.org>
> cc
> 	
> Subject
> 	Re: [wsrp-interfaces] Transient Properties
> 
> 
> 	
> 
> 
> 
> 
> 
> Some comments.
> 
> Subbu
> 
> Stefan Hepper wrote:
>  > Hi Mike,
>  > here my list of issues:
>  >
>  > - requiredScope, preferedScope
>  > should be removed, the portlet should only be specifying one scope, the
>  > consumer should be free to upgrade this scope to one that provides the
>  > same semantics but may last longer then the requested scope
> 
> I agree. It would be simpler and more deterministic to not have these two.
> 
>  > - wsrp:consumerRequest
>  > I don't think this is a useful shared state, I think portlets should use
>  > the nav state instead
> 
> But navState can not be used to share state across portlets. I see some
> use for this scope.
> 
>  > - wsrp:consumerSession, wsrp:consumerApplication
>  > can we combine these two into one state to make things less complex for
>  > portlet programmers? Something like wrsp:consumerContext. This scope
>  > should be per user and should have at least the lifetime of the current
>  > user session, but the consumer is free to extend the lifetime beyond the
>  > current user session.
> 
>  > Also I see problenms in allowing render links to influence these scopes.
>  > I would only allow to write to these scopes as return of a pbia or he.
>  > This may be a reason to create two seperate concepts: something like the
>  > public params that can also be influenced via URLs and a consumerContext
>  > that can be only changed as result of a pbia or he.
> 
> Could you elaborate on why it would be hard to update these properties
> via URLs?
> 
> Subbu
> 
>  >
>  >
>  > Michael Freedman wrote:
>  >  > This Thuirsday, we will continue our conversation on transient
>  >  > properties.  To better focus this discussion I would like to get a an
>  >  > understanding of which areas of the proposal cause concern.  This not
>  >  > only will allow us to focus our discussion but will enable me to
>  >  > evaluate whether there is a basic consensus on the core model or not.
>  >  > Can you please send this list your specific area's of concern (and why
>  >  > you have this concern)?  Where applicable, please be as specific as
>  >  > possible -- if you are concerned about the notion of supporting scopes
>  >  > in general you might list the issue as "scopes" and go on to 
> decribe why
>  >  > you think transient properties shouldn't have a defined scope.  If you
>  >  > have an issue with a specific scope -- say 
> wsrp:consumerApplication you
>  >  > would list it specifically and describe what your concern is.
>  >  >       -Mike-
>  >  >
>  >  >
>  >  >
>  >
>  >
> 
>