wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Comments on SessionParams and SessionContext
- From: Rich Thompson <richt2@us.ibm.com>
- To: OASIS WSRP TC <wsrp@lists.oasis-open.org>
- Date: Wed, 24 May 2006 07:18:21 -0400
I find it hard to swallow that moving
from nonexistent to existent isn't a change (i.e. nil != someValue). If
there are use cases providing value to distinguishing value changes from
existence changes, perhaps we should address those (one simple technique
is to carry the old value as well as the new value). I would note that
the state-based systems I am familiar with tend to ignore this semantic
difference while event-based systems usually define different events for
them such that parties caring about the semantic difference are informed
about it.
The changed and updates qualifiers on
the sessionProperty fields are intended to convey that the array is not
the full set of properties. Rather, the Portlet is informing the Consumer
about changes to its properties while the Consumer is requesting certain
properties have their values updated.
The purpose behind defining state-based
coordination is to have the page respond as a whole to end-user interactions.
I find this motivational statement more beneficial than lifting statements
about a subfield up a level. It would also help to have reasons why a conformance
statement about providing session property descriptions would belong in
the description of this field.
Rich
Subbu Allamaraju <subbu@bea.com>
05/23/06 05:09 PM
|
To
| OASIS WSRP TC <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| [wsrp] Comments on SessionParams and
SessionContext |
|
Regarding the questions raised by Mike on the current
wording of these
structures, I have the following comments:
-------------------------------------------------
SessionContext.changedSessionProperties
These properties are not necessarily "changed". They may also
be
properties that just came into being (pre-specified in
PortletDescription, of course). How about calling it "sessionProperties"?
-------------------------------------------------
SessionParams.sessionPropertyUpdates
The same comment applies for this field too. It would be simpler to just
call these sessionProperties that the portlet may be interested in.
On the question of the name of the SessionContext structure, I would not
want to change the name of a well-known structure, particularly since
most implementations will not be exposing such a name to
portlet/application developers.
-------------------------------------------------
Description of sessionParams (Sec 6.1.2):
The current description reads like
"... and coordination-oriented updates so that the portlet will be
able
to reference this state and therefore process the request in a manner
meeting the End-User's expectations"
The reference to "therefore process the request..." does not
seem be
adding any value to the semantics of sessionParams. As far as the
protocol is concerned, this is state that the portlet expressed interest
in. I would suggest the following:
sessionParams; The consumer uses this field to supply the Producer's
reference to a portlet session and any new/changed session properties.
The supplied session properties may have been supplied by other portlets
or by the consumer itself. The Portlet MUST declare the properties it
would like to receive in the sessionPropertyDescriptions field of its
PortletDescription.
Subbu
---------------------------------------------------------------------
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]