Re: [wsrp] Request scope support

[Stefan Hepper <sthepper@hursley.ibm.com>]

Hi Rich,
too me the behavoir is still not quite clear.

1. From an end user perspective I would have assumed that whenever I 
change the navigational state of a portlet this would also result in a 
new request. What does it mean to be in the same request cycle, but 
after the user has clicked on a button changing the navigational state 
the portlet now renders the data of a different customer?

2. Why is it the same request cycle when I change from page A to page B 
and back to page A. According to the current text the portlet on page A 
would still be in the same request cycle as no action or event had 
occured since it was last rendered. And how can the consumer keep track 
of this information efficiently? In order to support this flag and 
browser back button it would need to be encoded in the URL for each 
portlet the user has visited during the whole lifetime of a session.

3. What is the value for the initial portlet rendering? There was no 
action or event, so it is no new lifecycle? Seems strange to me as there 
is no "old lifecycle" to refer to.

4. How would the consumer know if the user got to the page where the 
portlet is placed and needs to be rendered via a bookmark or via user 
interaction? If the consumer needs to encode this flag in the URL it 
seems to me quite hard to implement.


I would like to get the nav state changs added to the criteria for being 
a new request and change the MUST to a SHOULD and explain that the 
consumer may not send a "true" in every case. Of course this change 
would mean that consumers will behave differently, but I can't imagine 
that everyone can and will implement the current proposal as it seems 
quite expensive to me.


Stefan


Rich Thompson wrote:
> 
> For those not on the Interfaces SC call today, the use cases regarding 
> Producers who have a concept of a user-request scope needing some 
> support from Consumers was discussed. There was a building consensus 
> toward having the Consumer supply an ID which changes only on action or 
> event processing, though most wanted to see a proposal in the context of 
> the spec and think through what the impacts of those changes would be on 
> reasonable Consumer  implementations before deciding whether or not to 
> include such support in v2. I agreed to draft such a proposal, but had a 
> problem with the scenario of a End-User jumping to a different state of 
> the page. This can easily happen via a bookmark, but also may happen 
> when the browser's back button is pushed. This caused me to change the 
> proposal to a style where the Consumer indicates to the Producer when it 
> knows a new requestCycle is starting via a boolean rather than being 
> more definitive by supplying an ID. I left the original attempt in (with 
> a strike through the text) so that people can easily consider that 
> option as well.
> 
> 
> 
> 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