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


I'm for having a TC call on Tuesday, but would propose to have it at 
noon EST in order to not have a conflict with the JSR 286 EG call.

Thanks.

Stefan

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
> 
> 




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