v17 comment, SessionProperties

[Richard Jacob <richard.jacob@de.ibm.com>]

Now that in v17 we testwise changed the transient properties into the new
model here are some thoughts:

- the change from the plain state model, where the Consumer managed and
distributed shared session state to portlets, to a signalling (or let's
call it eventing :-)) model seems to bring both concepts very close
together. For me the processing model is even quite the same as the
eventing model but we call it differently. The only difference I see is
that we specify that the payload (be it property value or event payload) is
stored within the session on the Producer side.

- the introduction of the wsrp:modifiedCoordinationContext event to support
the new transient property model seems even to strengthen my thoughts, now
to make the new transient property model work (somehow) one needs eventing.
This tie of the two concepts seems confusing to me and from just reading
the spec without my background I would have a hard time to understand what
the concept really is.

- it seems to me the mapping of the transient property model to the plain
eventing model is straigt forward: instead of having a property definition
for property "foo" define an in/out event named "fooChanged"; the payload
is the same. So is it really necessary to have two concepts accomplishing
nearly the same? Or is it rather confusing to developers?

- what I miss in the current wording is more clarity about when the
Consumer needs to assume a modified coordination context. The use cases
here are:
1. user logs out
in this case I would presume the consumer would call destroy session and
drop all session/cookie information, so if the user logs-in again a new
context is established automatically.
2. a wsrp session times out or sessionID changes
it seems that this enforces the consumer to throw the new mCC event and to
try to obtain the set of session properties.
The consumer needs to throw this event to all portlets EXCEPT to the one
who's session timed out (because the state is empty and the Consumer could
not distinguish this result from the others). Also the assumption here is
that all other portlets are still well coordinated (which might not be
quite true), otherwise the Consumer would have to choose which result set
from which portlet wins.
3. an invalidCookie fault is thrown
The same as above, the Conumser has to assume that the coordination context
is lost in that case, right?

I think we would need really more wording about the when/what and how's to
clearly specify the behavior. Currently it is very blurry.

- the modifiedSessionProperties can be also returned on a getMarkup
operation (which I still think is bad ;-) ).
But we remain calm about how such beast are redistributed. Remember the
gM() result is the last message in our whole processing chain.
So is the Consumer required to store these and pick them up in the next
phase? This would mean that a Consumer without some kind of session support
is not implementable.
Can the Consumer freely forget these? I would assume yes, since the whole
thing is optional.
And in that case don't we need to mention this in the spec?

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com