Re: [wsrp] (Required feature?) Transient property follow up

[Rich Thompson <richt2@us.ibm.com>]

Isn't the portlet's sessionID logically
a resource stored within the Consumer's session? I think we want the same
ends, I'm just trying to be careful that we don't make the semantics of
the scope confusing by how we do it.

As to the name of the feature, I think
that regardless of the scopes added in the future, this is logically an
extension of the portlet's session. Some technologies support multiple
scopes to such sessions, though all are limited to being within the Producer.
I think this feature simply expands the set of scopes to those that can
be supported within the Consumer, but doesn't semantics of it being the
portlet's session don't change. 

Rich

Michael Freedman <michael.freedman@oracle.com>

10/20/05 07:00 PM

To	wsrp <wsrp@lists.oasis-open.org>
cc
Subject	Re: [wsrp] (Required feature?) Transient property follow up

Yes, we are defining a consumer session scope -- I was
exploring if we needed to give assurances to the portlet that related to
the portlet session.  Maybe what I am looking for is something that
says the PortletSession is either equal to a piece of state managed within
the Consumer's Session -- hence producers that store state in the consumer
session know that its lasts at least as long as the portlet session state
and has the same semantic meaning in that it is scoped to an end user.
 Basically, I am wondering if we need language that allows the producer
to relate the state they might otherwise store in the portlet session.

As for the name Session Properties -- I am not sure, what happens in the
future if/when we add other scopes -- particularly one's that aren't related
to the user?  
   -Mike-

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>

10/18/05 03:21 PM

To	wsrp <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