Seems reasonable. Though I am not sure we should include "inactivity"
in the sentence as though ultimately allowed (because it is resource
management anyway) don't want to confuse consumer developers by having
them think they can/should manage the scope of this data distinctly
from the scope of the user session. I.e. I would expect that
inactivity would timeout the user session thereby releasing this
resource vs having a distinct timeout on the resource. [Though as I
said above this later is allowed under the definition of resource
management].
Also, to allay other concerns it probably useful to include a
descriptive paragraph that strongly discourages using transient
properties for state that is exclusively private to the producer.
Besides the obvious security issue of making this public/global, we
want to be sure that producers don't see this as a mechanism to offload
their session state management. We need to be clear that this is a
mechanism intended for coordination first and hence as a by product for
producer state management. We should encourage producers to limit the
degree of state managed via this mechanism as it impacts potentially
limited resources on the consumer.
-Mike-
Rich Thompson wrote:
I agree with both points ... the
portlet
developer has to consider the shared state to be dependable and the
spec
definitions has to contain provisions that allow Consumer management
its
own resources.
What if the conformance language
also
allowed for the Consumer to release resources for either inactivity or
as part of resource management?
Rich
Mike,
what do you suggest as consumer behavior for consumers with limited
memory available? How can they act in a compliant way? Are they allowed
to remove items from the property store? Or give back an error to the
portlet that the current properties are not stored?
Stefan
Michael Freedman wrote:
> I agree that folks should be discouraged from using this type of
> property when the state is exclusively private to the portlet. I
raised
> the issue however because we need to be clear whether this type of
> property is only used for communicating a state change between
portlets
> vs. representing shared state. If we want to do the former I
no longer
> understand how this conceptually differs from navigational
parameters
> other then that the scope is for the session, and would suggest we
need
> to re-express the APIs to merge the function into a single
concept.
Or
> alternatively merely remove session support altogether and force
folks
> to use events. I had thought, however, that we had decided
at the F2F
> that transient properties should represent shared state. I raised
the
> question because once you tell a portlet it can't rely on this
state
it
> can only be used as a means of data interchange between portlets
hence
> thought it needed to be required.
>
> -Mike-
>
> Richard Jacob wrote:
>
>>I'm not convinced that we should make this a required feature.
>>The shared session context provided here is really a loaded gun.
>>I'm afraid developers will use this not only for coordination
purposes
but
>>also for private data collection purposes.
>>Our experience is exactly this behavior. The biggest can they
can
get, they
>>stuff it in, because it's convenient.
>>And we had various talks about whether we enable a "better"
world and try
>>to teach, or whether we take some current practices as a given
and don't
>>support them (well), e.g. the famous method=GET discussion was
one example
>>here.
>>
>>We really need to be carefull in order to allow Consumers to
remain
>>scalable. Experience shows that blowing up the session size is
one of the
>>main scaling prohibitors.
>>I think it's a big difference between storing only the wsrp
session
ID in
>>the Consumer's session and a large amount of portlet data.
>>Consumers should be free to reduce the amount of resources they
want to
>>offer 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
>>
>>
>>
>> Subbu Allamaraju
>> <subbu@bea.com>
>>
To
>> 10/24/05 05:24 PM
wsrp <wsrp@lists.oasis-open.org>
>>
cc
>>
>>
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
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>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
|