OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsrp] Request scope support


agreed, one other example.

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 
                                       Richard Jacob/Germany/IBM@IBMDE     
             01/19/06 12:19 PM                                          cc 
                                       "Rich Thompson"                     
                                       <richt2@us.ibm.com>,                
                                       <wsrp@lists.oasis-open.org>         
                                                                   Subject 
                                       RE: [wsrp] Request scope support    
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




That's broadly what I understood. I'm raising the issue that phases may
not or seem to not complete because of network problems.

Regards,
Andre

-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 19 January 2006 11:07
To: Andre Kramer
Cc: Rich Thompson; wsrp@lists.oasis-open.org
Subject: RE: [wsrp] Request scope support

The intent of this ID or flag was to support JSF or similar technologies
which have a request scope attribute (because the don't seperate action
processing from render processing) as a "convienience object".
The idea brought up was to support such producer in determing when they
could throw away such a request scoped object and reinitialize it. The
assumption here is that because our protocol has two (three) distinct
request whereas JSF has only one request, the JSF producer would have to
store the request scoped beans in some other scope (e.g. session) and
mimic
the request scope.

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.

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]