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
