wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] TransientProperties
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Thu, 23 Jun 2005 09:35:02 -0400
I think there have been two use cases
raised for different sharing scopes:
1. The portlet is interested in receiving
coordination information, but doesn't want any values it sets exposed to
others. I think this is a case of the component asserting it knows more
about the overall environment than the composing framework. I would note
the component will often know that some information should not be shared
at all, but that is a simple matter of not sending these values to the
Consumer. Do people have use cases where the data needs to go through the
Consumer, but not be shared with other portlets?
2. Guidance about whether two instances
of a portlet being composed together should share data with each other.
I think the Consumer already knows whether two distinct instances should
share such data ... and if not (the normal), when various pieces of data
should be connected to which instance since this is likely to be a function
of how the composition is intended to work.
Rich
Stefan Hepper <sthepper@hursley.ibm.com>
06/23/05 06:26 AM
|
To
| Rich Thompson/Watson/IBM@IBMUS
|
cc
| wsrp <wsrp@lists.oasis-open.org>
|
Subject
| Re: [wsrp] TransientProperties |
|
Why would the producer care if the property is shared
or not? Isn't that
something we could leave up to the consumer? Wouldn't it be enough to
just specidy the parameter format so that the consumer can store and
manage these?
About the scopes: what about the loosely defined navigational scope that
lies somewhere between per request and session scope?
Stefan
Rich Thompson wrote:
>
> Wouldn't it be better to view these as two different scoping concepts,
> one is LifetimeScope and the other is SharingScope? I raise this because
> I suspect not only would additional lifetime scopes be added in the
> future, but also additional scopes for the sharing such data. This
also
> allows unifying the concepts, from the portlet's perspective, each
> transient property has a lifetime and a breadth within which it is
> shared (minimum = private, maximum = public). There would be no need
to
> distinguish the sharing breadth at runtime, though we should think
> carefully through the implications of multiple portlets indicating
> different sharing breadths for a particular property.
>
> I think the questions on managing these scopes in the midst of
> conflicting metadata will still result in the model where the Consumer
> maintains a store of transient properties and a mapping layer for
each
> portlet. This allows the property QName, lifetime and sharing scope
to
> all be dealt with at the portlet-specific layer while the bulk of
the
> coordination behavior happens at the shared layer.
>
> Rich
>
>
> *Michael Freedman <michael.freedman@oracle.com>*
>
> 06/21/05 05:10 PM
>
>
> To
> wsrp
<wsrp@lists.oasis-open.org>
> cc
>
> Subject
> [wsrp]
TransientProperties
>
>
>
>
>
>
>
>
> Here is the writeup I volunteered to produce last week which extends
the
> current notion of PublicParameters to add transient property like
> capabilities. This should get people's juices flowing:
>
> Summary:
>
> Address the various incoming requirements by adding two new concepts:
> 1. TransientProperties: properties
whose values are managed by
> the consumer for a transient length of time [as defined by a consumer
> scope].
> 2. Shared PublicParameters vs. Local PublicParameters:
> distinguish between two types of public parameters. Shared
public
> parameters are shared in that they are defined a single consumer managed
> namespace. Local public parameters aren't shared in that they
are
> defined in a per [wsrp] portlet namespace.
> The first concept allows a producer to indicate the lifetime this
> property should be maintained. Request means the property's
value is
> only maintained for the duration of the client request. Current
or new
> values must be established in each subsequent request. Session
means
> the property's value is maintained for the duration of the consumer's
> client/user session. While the session remains intact, the property's
> value is maintained until explictly set.
>
> The second concept allows a producer to indicate whether the property
it
> is placed in a global shared consumer space or a local per portlet
> space. The former allows two or more cooperating consumer component's
> to share a value while the later ensures the portlet has a discretely
> managed value [though this value may be impacted by others via a
> consumer supplied wiring mechanism].
>
> Note: An open, unresolved issue is whether the transient property
scope
> is considered part of the namespace or not. I.e. what do we
do if two
> portlets publish a shared public parameter foo.bar but each publishes
at
> a different transient scope [request and session]? Do we use
these
> scopes as "hints" and defer to the greater scope [session]?
Do we
> publish at each scope and view them as separate values?
>
> Setting values:
> A shared or local public parameter value can be set in a variety of
ways:
> 1. By the client -- we would define the
URL parameter name
> mapping to both shared and local public parameters so clients can
> express values for them directly in the request URL. Note: we would
have
> to define what happens if duplicate parameters appear in the request
for
> a scalar type.
> 2. In a portlet's Action or Render URL
- based on the name
> mapping defined above we would allow portlet's to render action and
> render URLs which directly express new values for either shared or
local
> public parameters.
> 3. As a result of an action or event.
> Details of each of these to be provided later if the general appraoch
is
> abgreed upon.
>
>
> Anyway: the structural details:
>
> For review:
>
> PropertyDescription
> [R] QName name
> [R] QName type
> [O] LocalizedString label
> [O] LocalizedString hint
> [O] string
capabilities[]
> [O] Extension extensions[]
> *
> TransientPropertyDescription extends PropertyDescription
> [R] string scope [wsrp:request,
wsrp:session, .... open ended
> list so new scopes can be added]*
>
> RuntimeContext
> [R] string userAuthentication
> [O] Key portletInstanceKey
> [O] string namespacePrefix
> [O] Templates templates
> [O] ID sessionID*
> [O] Property sharedPublicParameters[]
> [O] Property localPublicParameters[]*
> [O] Extension extensions[]
>
> -Mike-
> ---------------------------------------------------------------------
To
> unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs
in
> OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]