Re: [wsrp] Request scope support

[Richard Jacob <richard.jacob@de.ibm.com>]

I think the current proposal strenghtens my arguments I made yesterday.
It's not quite easy to implement such a message correlation on the consumer
side and the value it gives seems quite limited to me.
We seem already to have troubles to clearly define what such a cycle would
be, what it would mean and at the same time keep the features that WSRP and
JSR168 offers in terms of bookmarkability back button support, etc.
If we defined the requestCycle flag what would the difference really be in
letting the Producer set internally flag (without the protocol need to
transfer it). The Producer can easily conduct the same information on the
incomming request, i.e. if a pbia() or he() occurs on a portlet instance
(use the portletInstanceKey here) then it can consider it a new request
cycle.
I don't see the value in the protocol support to mimic this behavior.

Unfortunalty JSFdoesn't fit well into our model simply because it doesn't
clearly seperate action processing from rendering.
Now we seem to try to "retrofit" our protocol in such a manner that it can
act as a single phase protocol.
I think consequently this might break our intended behavior which we might
not have foreseen yet, examples here are cachability, back button,
bookmarks.

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


                                                                           
             Rich Thompson                                                 
             <richt2@us.ibm.co                                             
             m>                                                         To 
                                       wsrp@lists.oasis-open.org           
             01/18/06 11:09 PM                                          cc 
                                                                           
                                                                   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 [attachment "RequestID_proposal.doc" deleted by Richard
Jacob/Germany/IBM]
---------------------------------------------------------------------
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