[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Suggestion to change the newNavigationalContextScope event intoa navigational parameter
Well, it's not the first and the last amusing thing we encountered ;-)
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
Michael Freedman
<michael.freedman
@oracle.com> To
WSRP TC <wsrp@lists.oasis-open.org>
09/28/06 11:44 PM 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]