[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] (Required feature?) Transient property follow up
I agree with the language proposed below. Of course, we need to read it in the context of the spec :) On the naming issue, I agree with Mike's concerns on extensibility in future versions of the sepc as well vendors. The term "transient" is more extensible. Subbu Rich Thompson wrote: > > But the equivalence would only hold if the scope is wsrp:portletSession. > Since we are defining a scope related to the End-User's interactions > with the Consumer, I would think any requirements should relate to those > interactions rather than the interactions of the Consumer with the > portlet. Perhaps something like: > The Consumer MUST initiate the wsrp:consumerSession scope whenever a new > set of interactions with an End-User are initiated and MUST NOT > terminate this scope until either those interactions cease or resources > related to the End-User's interactions are released due to inactivity. > The Consumer MUST NOT automatically null out all settings of transient > property values within the wsrp:consumerSession scope. > > I think this pair ends up making the feature required of Consumers, > provides a distinct definition of the scope and makes transient > properties usable by portlet developers. > > Any thoughts on renaming this feature to "Session Properties"? > > Rich > > > *Michael Freedman <michael.freedman@oracle.com>* > > 10/19/05 03:33 PM > > > To > Rich Thompson/Watson/IBM@IBMUS > cc > wsrp <wsrp@lists.oasis-open.org> > Subject > Re: [wsrp] (Required feature?) Transient property follow up > > > > > > > > > For the portlet that is deciding to use the session Transient property > as an alternaitve to storing state it might otherwise store in a > portletSession wouldn't there be an interest in whether or not there is > a relationship in how the consumer manages these two? My point in > making them equivalent is that portletSession becomes opaque or private > session data while consumerSessionScoped transient property become > public session data. > -Mike- > > Rich Thompson wrote: > > Your two questions are sufficiently different that I suggest splitting > the discussion into two threads. > > Relative to making Transient Properties a required feature. I would > agree that for this feature to be truly useful, portlet developers need > to have it be dependable. Any arguments against making it required? > > If we do make this a required feature, I don't think it is the lifetime > that needs to be clarified. Rather, it is prohibiting a claim for > support that simply has a Consumer component which always sets property > values to null. > > On a similar note, I have been thinking lately that a better name for > these would be "Session Properties". Transient Properties is a bit too > ambiguous and tends to raise the questions about why both these and > Navigation Parameters. No matter what additional scopes are defined, > what we have defined is semantically an extension of the Portlet's session. > > Rich > > *Michael Freedman **_<michael.freedman@oracle.com>_* > <mailto:michael.freedman@oracle.com> > > 10/18/05 03:21 PM > > > To > wsrp _<wsrp@lists.oasis-open.org>_ <mailto:wsrp@lists.oasis-open.org> > cc > > Subject > [wsrp] Transient property follow up > > > > > > > > > > > A couple of questions/issues I came up with post F2F on Transient > properties: > 1. Should the meta data that describes transient properties be > improved to support a notion of aliasing? > Is there value in distinguishing between the name the portlet receives > the transient property as and the set of [coordination] names that > identify this property to the consumer? The use case is two [sets of] > portlets that are developed independently each with their own > namespace/vocabulary for properties sometime afterwards understanding > that coordination could also occur between them because the property > [semantics] are the same. Current model requires the one/both to change > its implementation with potential backwards compatibility impacts. We > could however offer another field in the TransientPropertyDescription > that is an array of aliases which identify other identities of the same > property. Should we add this to our 2.0 design? > > 2. By defining a specific/known duration for consumerSession > scope can we make this a required feature in 2.0? > My understanding from our F2F discussions is that producers couldn't > rely on transient properties to hold internal state because though we > required support for this feature we said it was valid for the consumer > to claim support by merely always sending/representing a null value > [i.e. value always out of scope]. I think this is a severly restricts > the value of transient properties and makes them more akin to > NavigationalParameters. Since all we are defining is the > consumerSession Scope and that we though unstated this scope is > implied/must exist in WSRP 1.0 to support managing portletSessions can > we stengthen our proposal by requiring that a transientProperty of > consumerSessionScope must be maintained for the exact amount of time > that the consumer maintains the portlet's session assuming that portlet > session has an infinite lifetime from the perspective of the producer? > [I.e. portlet session timeouts aren't a factor in this]. By equating > this transientProperty scope to the same scope that the consumer manages > portletSessions on we create an equivalence between the management of > public session state and opaque session state meaning the portlet can > now depend on the public state. > -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_ > > --------------------------------------------------------------------- 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]