[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Type for supportedFeatures
Agreed on the second one. Let's stay compatible with v1.
Regarding the first one: on the other hand we could stay here consistent
with the other fields and leave it as string. But mandate for custom
features to use "qualified-like" strings.
I think the same way we do for custom modes and window states.
But anyway, I can leave with Qname here.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Rich Thompson
<richt2@us.ibm.co
m> To
wsrp <wsrp@lists.oasis-open.org>
07/05/2005 06:55 cc
PM
Subject
[wsrp] Type for supportedFeatures
Subbu has suggested to me that a more appropriate type for
supportedFeatures would be QName (rather than string) as this then enforces
namespacing values. Although this introduces the standard issue of defining
the namespace URN (rather than just the prefix), I think it would be a good
change (and manageable within the WSDL).
As a corollary ... should we consider the same change for similar fields
(userScopes, mode, windowState & userCategories)? I think not in order to
stay compatible with v1, but want to at least raise the question.
Rich
Rex Brooks
<rexb@starbourne.com>
To
06/30/05 12:13 PM Michael Freedman
<michael.freedman@oracle.com>, wsrp
<wsrp@lists.oasis-open.org>
cc
Subject
Re: [wsrp] Re: TransientProperties
Thanks Mike,
Hopefully we can bring back transient properties scopes. It will be
particularly useful for a number of reasons related to the Emergency
Management field, but it will also be useful for location-based services.
With Keyhole in Google,
http://earth.google.com/
Geospatial is about to make a splash. I suspect Version 3 will be impacted
by greater implementer feedback. Too bad there's a delay in downloading it,
but that's beta, for ya.
Ciao,
Rex
At 7:56 AM -0700 6/30/05, Michael Freedman wrote:
Rex Brooks wrote:
[wsrp] Re: TransientProperties
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
--------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]