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


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]