Re: [wsrp] Suggestion to change the newNavigationalContextScope event intoa navigational parameter

[Rich Thompson <richt2@us.ibm.com>]

I commented on the last TC call that
you might find that character of the proposal amusing, but would also note
there are significant differences.

First of all, the idempotency issue;
consider the following sequence of messages/actions:
1. A user uses HTTP GET to request a
portal page which contains a portlet requiring the wsrp:newNavigationalScope
event
2. The Consumer sends this portlet the
event. Since event processing is allowed to change state, the portlet (incorrectly)
uses the opportunity to change state.
3. The Consumer gets all the markup
and returns it to the UA

The problem is that the http protocol
requirements for step #1 include idempotency while the WSRP protocol allows
non-idempotent behavior in step#2.

The significant difference from the
original proposal is that the Consumer only changes its ID at the same
times that it would have sent the event. Any finer grained keying (e.g.
the portlet has pushed its navState delta to the Consumer mid-scope) would
be done by the Portlet within its navState. As a result, this combines
the two proposals to fully solve the use case without potentially breaking
idempotency.

Rich

Michael Freedman <michael.freedman@oracle.com>

09/28/2006 05:44 PM

To	WSRP TC <wsrp@lists.oasis-open.org>
cc
Subject	Re: [wsrp] Suggestion to change the newNavigationalContextScope event into a navigational parameter

I am both a little amused and confused by this thread. 
I am amused by seeing we have come full circle back to my original proposal
whereby the consumer is responsible for maintaining and sending a navScope
ID.  I am confused because I don't see the idempotency issue. 
As for defining as solution as an extension I continue to find this unacceptable. 
This problem was created/exists because of how we changed/clarified the
language/semantics in handling navigationalState for getResource/resourceURLs. 
I continue to believe we can't move foward with this proposed/adopted change
without defining a corresponding solution to this navState delta problem
as its all part of the solution/change.
     -Mike-

Richard Jacob wrote: 
Hi all,

back from my vacation I'm quite surprised that the raise of the event came
in as a must requirement.
However, reading thru this discussion it seems folks are agreeable to
removing it.
Given the technical discussion I strongly agree that this event should
not
be in the spec as is and that the navParam proposal fits way better.

I didn't quite understand the minutes and the implications noted there.
Could someone give me an update?
  
"Stefan's proposal to standardize a navigational
parameter rather than an
    
event:
   > a.     Removes the possibility of portlets changing
state on what
      should be an idempotent request
   > b.     Rich to explore with the OASIS staff whether
removing a
      conformance statement can constitute an editorial
change.
   Do we have an outcome here or will this be discussed at the next
TC
      meeting?

   > c.     In either case, do Stefan’s proposal as
an extension."
   What does that mean? Does this mean that if this is considered
not being
      only an editiorial change, it stays in the spec AND
we have Stefans
      proposal? If this is the case I would find it very
awkward to put a
      solution in the spec and provide immediatly an alternative
as an
      extension.

Concerning your questions, Subbu:
  
a. What is the impact of not making this change?
    
We had a solution in the spec which we all seem to
agree that it is
techically not the best idea. The reason for this is, I think, that this
is
a last minute change with perhaps more impact that we have thought and
we
have not given ourselves enough time to think thru. Therefor I would really
prefer to drop a solution from the spec where we're already seem to have
convinced ourselves that it is not optimal.

  
b. What is the benefit of making this change?
    
Having a cleaner solution which seems to fit way better.

  
c. What is the cost of making this change, and does
the cost justify the
change?
    
I think this really is an editorial change. So I don't
see a cost here.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


                    
                     
                     
          
             Wesley      
                     
                     
     
             Budziwojski      
                     
                     
             <Wesley.Budziwojs  
                     
                 To 
             ki@Sun.COM>
              Rich Thompson <richt2@us.ibm.com>
  
             Sent by:      
                     
                     
cc 
             Wesley.Budziwojsk    
    WSRP TC <wsrp@lists.oasis-open.org>
             i@Sun.COM
                     
                     
Subject 
                    
                  Re: [wsrp]
Suggestion to change the 
                    
                  newNavigationalContextScope
event   
             09/15/06 07:42 PM    
    into a navigational parameter       
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          




Benefit 2 leads also to avoiding kind of potential "awkwardness"
for a
consumer to implement/deal with eventing mechanism even though
the consumer may choose not to support the eventing feature in general.

Wesley


Rich Thompson wrote:

  
I agree that those are the key questions (& the
ones Stefan & I worked
through when he pinged me about this idea).

Not making this change leaves the possibility that an initial page
load not be idempotent, even if http get was used to request the page
of the Consumer.

I see two benefits of making this change:
 1. Keep idempotency possible for those cases where other protocols
require it.
 2. Remove a requirement that Consumers generate an event

The cost is tightening up the window for getting the OASIS submission
packet together before Oct 15. If people think this is a good idea, it
doesn't require us to miss that deadline though.

Rich


*Subbu Allamaraju <subbu@bea.com>*

09/14/2006 11:09 AM


To
           WSRP TC <wsrp@lists.oasis-open.org>
cc

Subject
           Re: [wsrp] Suggestion to change the
    
newNavigationalContextScope event
  
into a navigational parameter









I would also like to apply some release management-like criteria and ask
some questions for this change:

a. What is the impact of not making this change?
b. What is the benefit of making this change?
c. What is the cost of making this change, and does the cost justify the
change?

This should help members make a quick decision on whether to support or
not support this proposal.

Regards,
Subbu

Rich Thompson wrote:
    
I like the idea of splitting the key into two parts
(a Consumer
      
supplied
    
key to identify the scope and a Portlet supplied key
to identify when
Producer-stored deltas are pushed into navState). In particular, it
cleanly solves the concern we had about the initial page load not
obeying idempotency requirements (i.e. the portlet could change any
state during event processing).

On the process side, we are allowed to withdraw the spec from the
      
public
    
review, make modifications and then resubmit it for
public review. The
one possibility I can see for this still meeting the target of
submitting to OASIS on Oct 15 would be to hold a TC call next
      
Tuesday to
    
hold three votes:
  1. Witrhdraw pr-02 from the current public review
  2. Approve a wd-21 as cd-04
  3. Submit cd04 to a 15 day public review as pr-03

If we can get all the process items accomplished next week, the 15 day
public review on pr-03 would end just before the F2F. The submission
vote could then happen at the F2F. That gives us a bit less time to get
the submission packet together, but it would still be doable if people
have their usage and IPR statements all in place.

Mary, please correct me if I have misrepresented some portion of the
process.

If people think this is a good way to go, please respond regarding
holding a TC call next Tuesday. If people are in favor, I will
      
produce a
    
wd-21 with this change by Monday AM.

Rich


*Stefan Hepper <sthepper@hursley.ibm.com>*

09/14/2006 09:36 AM


To
                 WSRP TC <wsrp@lists.oasis-open.org>
cc

Subject
                 [wsrp] Suggestion
to change the
      
newNavigationalContextScope event into
    
a navigational parameter








Hi,
when thinking about how to map the event that we introduced in draft 2
on the JSR 286 I still disliked that this event breaks the idempotency
of render and thus is against W3C recommendations. Thus I tried to find
a solution that addresses the use case we had and does not break the
idempotency for render.

My suggestion is to use a container provided navigational parameter
(e.g. wsrp:navigationalContextScopeID) to all portlets interested in
this context ID. This ID would be constant for a current navigational
context scope and would change if the consumer decides to start a new
scope (which is currently modeled with sending a new event). The
      
portlet
  
could then use the consumer provided ID and add its
own ID and use this
to manage its part of the nav state.

What do people think about this from the technical side?


Another question is how to get a change into the spec at this stage. I
think we would need to abort our current review and submit an updated
      
to
  
be reviewed.

Rich, can you tell us what this would require?

Sorry that it took me this long to come up with this idea.


Stefan


      
Register now for BEA World 2006 --- See http://www.bea.com/beaworld<<
        
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries
 and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted
 and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.