Re: [wsrp-interfaces] Transient Properties

[Rich Thompson <richt2@us.ibm.com>]

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