Rex Brooks wrote:
Yup, Mike,
Ya definitely got my attention.
Q1: How are we planning to provide bookmarking/refresh for
TransientProperties in session? If it remains intact until explicitly
set, is it reasonably safe to push out to the user as
navigationalState? This has some impacts on Govt/Emergency Management
networks, and it may determine if I try to use v2.0 for the collected
gaggle of pilots I'm managing this summer.
This is one of the arguments for making it a
producer recommendation but consumer choice. Unlitmately the consumer
decides what is bookmarkable by limiting the scope of such data.
Q2: What happens if I need to leave Request on for the length of
an "incident, " which can span hours to as much as a month,
but needs to specifically be transient so that scope of the
"incident" is maintained. It is also likely to be a fairly
hairy scalability problem, depending...?
Again, this is a consumer choice and I suspect
most consumers would not keep transient data around this long. I
suspect this usage fits better with producers that use events to impact
internal state that they can manage via a persistent cache.
Interesting,
Rex
At 5:54 PM -0700 6/29/05, Michael Freedman wrote:
Second round of ideas for supporting
transientProperties based on last weeks discussion:
On the issue of "local" vs "shared" -- I think we
can live with Rich's suggestion that this noth be expressed, rather it
be left to consumer policy. I.e. instead of relying on
capabilities we should just state that identical property name
reference [in distinct portlet usages] are assumed to refer to the
same property/value unless a Conumer policy indicates
otherwise.
On the issue of scoping transient properties -- change what was
proposed last week to reflect that the producer is requesting not
demanding a scope. i.e. call the field "preferredScope"
vs. "scope" reflecting our preference that the consumer has
the ability to manage the transient scoping as it sees fit.
This would leave us with:
PropertyDescription
[R] QName
name
[R]
QName type
[O] LocalizedString label
[O] LocalizedString hint
[O]
string capabilities[]
[O]
Extension
extensions[]
TransientPropertyDescription extends PropertyDescription
[R] string
preferredScope [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
publicParameters[]
[O] Extension
extensions[]
-Mike-
Michael Freedman wrote:
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
>
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309
|