>
> As I said in another answer I'm also not convinced about the value of this
> flag and am argumenting that it a) brings complications to the consumer
> implementation b) is not cleanly defined and c) can be done by the producer
> itself.
Our team also agrees that this can be done by the producer itself. I
will send a follow up mail.
Subbu
>
> Mit freundlichen Gruessen / best regards,
>
> Richard Jacob
> ______________________________________________________
> IBM Lab Boeblingen, Germany
> Dept.8288, WebSphere Portal Server Development
> WSRP Team Lead & Technical Lead
> WSRP Standardization
> Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
> Email: mailto:
>
>
>
> "Andre Kramer"
> <andre.kramer@eu.
> citrix.com> To
> "Rich Thompson"
> 01/19/06 10:22 AM <>,
> <>
> cc
>
> Subject
> RE: [wsrp] Request scope support
>
>
>
>
>
>
>
>
>
>
> Both request and reply messages may be dropped by the network (e.g. some
> proxy in a forwarding chain). The resulting uncertainty about the state of
> a action/event/render cycle implies that a producer could at best
> communicate it’s intention to initiate a new cycle (e.g. via a
> monotonically increasing counter rather than a boolean). Having missed the
> call, I’m not clear on the benefits (if any) this would bring. At best a
> consumer could tell if it had recently seen an action or event the producer
> associates a render request (having the same producer set identifier) by
> keeping recent action (ids) in a consumer side cache?
>
> What about leveraging the existing ability to return markup from actions
> and events? At least this allows two phases (not three) to be collapsed.
> Here, events become a sort of “action” that (like actions) result in a new
> (consumer) cacheable rendering. Of course, this implies that producers
> don’t just throw away such markup returns and that all events are
> independent of action request values. That may be a recommendation we
> should make (always make events independent of the initiating action)?
>
> Regards,
> Andre
>
>
> From: Rich Thompson [mailto:]
> Sent: 18 January 2006 22:10
> To:
> Subject: [wsrp] Request scope support
>
>
> 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
