[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] Transient properties
I agree let's discuss the concepts.
regarding:
1. this is feasible, portlets should be able to declare what they intend to
receive
2. I'm not sure if this is what we really need. It seems to complicate
things. I would prefer to keep it simple and stick with one simple lifetime
definition.
The proposed 5 (or 6,7?) lifetimes are to much otherhead for me which I
expect programmers not to follow and fully understand.
Remember our POST vs. GET discussion and the statement that this is even
not well understood in the web.
The implication of these lifetimes leave to many open questions and
required considerations of the possible implications on the programmer
side.
I will comment on the scopes seperatly.
3. I would handle this in the same way as events/properties. A transient
property (Q-)name identifies the property and if two portlets declare it,
it is considered to be the same. Options for not sharing the same property
are complicating things. The consumer is (similar to events) not required
to do the distribution?
4 yes this is what we need results of actions and on renderURLs(? - has
some interesting implications)
To your question below:
If we keep the model simple and really consider the properties being a
transparent navState then the answer is simple: yes! this is an idemponent
operation.
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
interfaces
09/07/2005 01:23 <wsrp-interfaces@lists.oasis-open.o
PM rg>
cc
Subject
Re: [wsrp-interfaces] Transient
properties
I think these are good questions, but also think that we should focus first
on the overall model and debate the semantics/value of particular scopes
once we agree that introducing a multi-scoped transient property model
makes sense.
This proposal includes:
1. A means by which Portlets declare state which the Consumer must
instantiate if it is going to use the Portlet.
2. A recognition that state can have various lifetimes and a means by which
the Portlet and Consumer cooperatively establish the lifetime for each
property.
3. A strong encouragement that Consumers cause multiple declarations of the
same name to be shared across the declaring Portlets. This leaves room for
some edge cases where the Consumer application needs to not share such
properties in order to provide intended results while establishing the
normal case being the sharing of such properties.
4. Property values can be set by any constituent (while this was not called
out, I presume this means on responses from pbia() and he(), on URLs and by
any Consumer component)
In addition to determining whether we find value in such a model, we should
also debate where introducing such a model would break our normal mapping
of RESTful behavior (the key issue being whether an http get on render and
resource URLs results in idempotent processing on both the Consumer and
Producer). What guidance would we provide such that a render URL setting
property values could be processed in an idempotent manner that allows it
to be replayed?
Rich
Stefan Hepper
<sthepper@hursley.ibm.com>
To
09/07/05 05:36 AM Michael Freedman
<michael.freedman@oracle.com
>
cc
interfaces
<wsrp-interfaces@lists.oasis
-open.org>
Subject
Re: [wsrp-interfaces]
Transient properties
Hi Mike,
could you provide some use cases for these different scopes?
- why would you need a pre client request scope? Isn't that violating
the MVC pattern where the render should be replayable?
- what is the use case for the consumer session scope? Why would we
allow to change the consumer session state with a render link?
- same for application scope, why can you modify it with a render link?
Stefan
Michael Freedman wrote:
> Attached is a proposal for supporting transient properties. You may
> recall that in mid-August we decided to make one last push to see if we
> could define transient properties in 2.0 vs relying on public parameters
> [and needing to retrofit in 3.0]. Please review and comment asap as
> there isn't much time to refine this before needing to make the go/no go
> decision for 2.0. -Mike-
>
> ------------------------------------------------------------------------
>
>
> Transient Properties
>
>
> Definitions:
>
> Transient Property: a piece of shared consumer managed state with a
> defined-persistent lifetime declared by the producer and supplied to
> that producer in all non-initialalization calls in its Markup port
> (required feature in 2.0).
>
>
> Summary
>
> Transient properties:
>
> * a piece of shared ... state: the property can be set/received by
> any constituent of the consumer including the declaring portlet.
> * are consumer managed state: the consumer maintains the property
> and supplies it to the producer at appropriate times.
> * have a defined non-persistent lifetime: lifetimes are defined by
> scope (names). The following names are reserved/predefined:
> wsrp:consumerRequest, wsrp:navigationalState,
> wsrp:consumerSession, and wsrp:consumerApplication. [To fit into
> our existing declarative model we will also need wsrp:persistent
> and wsrp:registration, though these don't pertain to transient
> properties; see below for details]
> * are declared by the producer: the basic declaration includes a
> name, type, suggested default, minimum required scope, and
> preferred scope.
> * supplied to that producer on all non-initalization call in its
> Markup port: values for each property declared by that portlet and
> maintained by the consumer are sent on each invocation of
> PerformBlockingInteraction(), HandleEvents(), GetMarkup(), and
> GetResource().
> * (required feature in 2.0): Consumers must support transient
> properties with at least wsrp:consumerRequest and
> wsrp:navigationalState.
>
> Scopes:
>
> * wsrp:consumerRequest: in this scope the property is maintained
> for the lifetime of the consumer request. I.e. one pass through
> our 3-step protocol. This enables data management within a single
> request lifecycle [something not currently doable in WSRP 1.0] .
> Though this scope can be used for intra-lifecycle coordination
> its most likely used by the portlet itself to support/manage such
> a notion of scope in itself.
> * wsrp:navigationalState: in this aintscope the property is
> maintained for the same duration as the consumer maintains the
> portlets' navigationalState. This enables the coordination at the
> same level as navigational state is being maintained. Its
> introduced not only because its reasonable to tie this
> coordination lifetime to the same lifetime as something that
> already exists [navigationalState], but also because it should be
> easy for consumers to do so.
> * wsrp:consumerSession: in this scope the property is maintained for
> the lifetime as the consumers client/end-user session.
> * wsrp:consumerApplication: in this scope the property is maintained
> for the lifetime that the consumer itself is active.
>
> How they work:
>
> * TransientProperties are declared in PortletDescription [though
> described in ServiceDescription].
> * The requiredScope field must come from the set of scopes consumers
> are required to support [consumerRequest and navigationalState].
> The preferredScope field may name any scope including a custom
> scope. The requiredScope field must be of equal or lesser scope
> then the preferredScope. Note: do we think that WSRP 1.0
> adequately defines/requires the ntion of consumerSession scope?
> If so we can add this to the list of required scopes.
> * The consumer uses the declaration to create/manage the property.
> The property qname identifies the property. Consumers are
> strongly encouraged to recognize identical name/type declarations
> from different portlets as declaring the same property as
> properties are commonly used for data coordination. In such a
> case only one transient property is maintained and its value is
> shared between all declaring parties. The consumer is free to
> choose any scope equal to or higher then the scope specified in
> requiredScope. The consumer is free to move the property to a
> different scope at any time as long as it doesn't violate the
> stated minimums. This later is provided so that when portlets get
> added to a page at runtime, the consumer can upscope an existing
> transient property it wants to share.
> * The consumer passes the property name, value, and current scope on
> each invocation of the PerformBlockingInteraction, HandleEvents,
> GetMarkup, and GetResource when that property has a non-null
> value. When a property is out of scope it is has a null value.
> * The producer uses the property values as it sees fit. The
> producer recognizes the absence of a passed property as an
> indication that the properties value is null [or it is out of
scope].
> * The producer/portlet can set a property value in the response from
> a PerformBlockingInteraction and HandleEvents and by encoding the
> action of setting the property in a renderURL.
>
>
> Details:
>
>
> PropertyDescription:
>
> change to:
> PropertyDescription
> [R] QName name
> [R] QName type
> * [O] string preferredScope
> [O] string requiredScope
> [O] Property default*
> [O] LocalizedString label
> [O] LocalizedString hint
> [O] string capabilities[]
> [O] Extension extensions[]
>
> from:
> PropertyDescription
> [R] QName name
> [R] QName type
> [O] LocalizedString label
> [O] LocalizedString hint
> [O] string capabilities[]
> [O] Extension extensions[]
>
> Discussion:
> I added the preferredScope, requiredScope, default fields into
> PropertyDsecription because a ModelDescription must be used to define
> the set of transient properties. The way we have defined
> ModelDescription requires everything be in PropertyDescription. These
> fields are optional. The set of predefined scopes are:
>
> wsrp:consumerRequest: duration of a single client/consumer request
> wsrp:navigationalState: duration of navigationalState in this
consumer
> wsrp:consumerSession: duration of consumer's user session
> wsrp:consumerApplication: duration of active consumer.
> wsrp:persistent: duration is persistent across consumer activations.
> wsrp:registration: duration of this registration
>
> The default preferred/required scope value is based on the context
> of the description. For registration properties its
> wsrp:registration [this is the only valid value]. For a portlet's
> properties its wsrp:persistent [again this is the only valid value].
> In the case of transient properties its wsrp:consumerRequest.
>
>
> PortletDescription:
>
> change to:
> PortletDescription
> [R] Handle portletHandle
> [R] MarkupType markupTypes[]
> [O] ID groupID
> [O] LocalizedString description
> [O] LocalizedString shortTitle
> [O] LocalizedString title
> [O] LocalizedString displayName
> [O] LocalizedString keywords[]
> [O] ID portletID
> [O] QName publishedEvents[]
> [O] QName handledEvents[]
> * [O] ModelDescription transientPropertyDescriptions*
> [O] string userCategories[]
> [O] string userProfileItems[]
> [O] boolean usesMethodGet
> [O] boolean defaultMarkupSecure
> [O] boolean onlySecure
> [O] boolean userContextStoredInSession
> [O] boolean templatesStoredInSession
> [O] boolean hasUserSpecificState
> [O] boolean doesUrlTemplateProcessing
> [O] Extension extensions[]
>
> from:
>
> PortletDescription
> [R] Handle portletHandle
> [R] MarkupType markupTypes[]
> [O] ID groupID
> [O] LocalizedString description
> [O] LocalizedString shortTitle
> [O] LocalizedString title
> [O] LocalizedString displayName
> [O] LocalizedString keywords[]
> [O] ID portletID
> [O] QName publishedEvents[]
> [O] QName handledEvents[]
> / [O] ModelDescription publicParameterDescriptions -- removed/
> [O] string userCategories[]
> [O] string userProfileItems[]
> [O] boolean usesMethodGet
> [O] boolean defaultMarkupSecure
> [O] boolean onlySecure
> [O] boolean userContextStoredInSession
> [O] boolean templatesStoredInSession
> [O] boolean hasUserSpecificState
> [O] boolean doesUrlTemplateProcessing
> [O] Extension extensions[]
>
> Discussion:
> publicParameters were merely transient properties at
> wsrp:navigationalState. To add transientProperties we merely replace
> the publicParameterDescriptions field with a
> transientPropertyDescriptions field.
>
>
> Property Types:
>
> change to:
> Property
> [R] QName name
> [O] string xmlLang
> [O] Object value[]
> * [O] string scope*
>
> from:
> Property
> [R] QName name
> [O] string xmlLang
> [O] Object value[]
>
> Discussion:
> With the addition of transient properties there is now a need/interest
> in representing the [current] scope of a given property . We require
> this field have a value when passing transient properties otherwise its
> optional.
>
>
> RuntimeContext:
>
> change to:
> RuntimeContext
> [R] string userAuthentication
> [O] Key portletInstanceKey
> [O] string namespacePrefix
> [O] string interactionFieldPrefix
> [O] Templates templates
> [O] ID sessionID
> * [O] Property transientProperties[]*
> [O] Extension extensions[]
>
> from:
> RuntimeContext
> [R] string userAuthentication
> [O] Key portletInstanceKey
> [O] string namespacePrefix
> [O] string interactionFieldPrefix
> [O] Templates templates
> [O] ID sessionID
> / [O] Property publicParameters[]/
> [O] Extension extensions[]
>
> Discussion:
> Again, to pass transientProperties to performBlockingInteraction,
> handleEvents, getMarkup, and getResource, we merely replace the
> publicParameters field with a transientProperties field.
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]