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] Suggestion to change the newNavigationalContextScope eventinto a navigational parameter

Sorry, I still don't get it.  I need a more detailed explanation to understand whether this is merely a theoretical problem. We can discuss in tomrorow's concall.

Event case:  

Rich Thompson wrote:

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.


Michael Freedman <michael.freedman@oracle.com>

09/28/2006 05:44 PM

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

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.

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

  > 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

  > 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

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

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

            <Wesley.Budziwojs                                          To
ki@Sun.COM>               Rich Thompson <richt2@us.ibm.com>  
            Sent by:                                                   cc
            Wesley.Budziwojsk         WSRP TC
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.


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.


*Subbu Allamaraju

09/14/2006 11:09 AM

          WSRP TC

          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

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


Rich Thompson wrote:

I like the idea of splitting the key into two parts (a Consumer


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


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

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.


*Stefan Hepper

09/14/2006 09:36 AM

                WSRP TC

                [wsrp] Suggestion to change the

newNavigationalContextScope event into

a navigational parameter

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


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


be reviewed.

Rich, can you tell us what this would require?

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



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.



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