Re: [wsrp] Proposal - Session Properties

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

This was definitely one of the areas
where we had not reached consensus. As I drafted the proposals, I took
the tack that the protocol ought to seek to provide a consistently synchronized
view to the End-User whenever possible. I expected this to generate discussion
relative to each of the proposals concerning the value of ensuring such
a consistent view vs the cost required. For me personally, this trade-off
is key and will likely end up determining which of the proposals (including
any additional ones) I support.

Rich

Stefan Hepper <sthepper@hursley.ibm.com>

06/14/06 08:56 AM

To	WSRP TC <wsrp@lists.oasis-open.org>
cc
Subject	Re: [wsrp] Proposal - Session Properties

Thanks Rich for the write-up.

One question about proposal 1.:
why do you require this for changes propagated back in gm: "The Consumer
MUST retain these updates for distribution to other Portlets on the next
user interaction."

Proposal 1. is very similar to what we've defined in JSR 286, but there
we don't require that these changes are propagated back. Which means 
things can get out of sync, but on the other hand I don't see how you 
can guarantee this given that it is more likely to get race conditions
for changes in render than in any other lifecycle method due to the 
ability to call render in parallel.

Stefan

Rich Thompson wrote:
> 
> I was requested to extract the session property work into an extension
> feature/proposal. As part of doing this, I generated the three proposals
> that have been mentioned to-date, leaving room for issues & resolutions
> for each. The first draft of this can be found (& updated) at
> http://wiki.oasis-open.org/wsrp/Session_Property_extension.
> 
> In doing this work, it became clear that ExtensionPart ought to have
a 
> name field. The semantics would be that the name (type==QName) at
the 
> ExtensionDescription level defines the semantics of the extension
while 
> the name (type==QName) at the ExtensionPart level defines the XML
> element name for the child of the extensions element (this would also
> become the deserialized variable name for many common toolings).
> 
> Rich 
> ---------------------------------------------------------------------
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