OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] Comments on SessionParams and SessionContext



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]