Re: [wsrp] Request scope support

[Subbu Allamaraju <subbu@bea.com>]

> 
> 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:richard.jacob@de.ibm.com
> 
> 
>                                                                            
>              "Andre Kramer"                                                
>              <andre.kramer@eu.                                             
>              citrix.com>                                                To 
>                                        "Rich Thompson"                     
>              01/19/06 10:22 AM         <richt2@us.ibm.com>,                
>                                        <wsrp@lists.oasis-open.org>         
>                                                                         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:richt2@us.ibm.com]
> Sent: 18 January 2006 22:10
> To: wsrp@lists.oasis-open.org
> 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