[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
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]