wsrp-interfaces message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Interfaces: WSRP 2.0 open issues
- From: Michael Freedman <michael.freedman@oracle.com>
- To: wsrp@lists.oasis-open.org, wsrp-interfaces@lists.oasis-open.org
- Date: Wed, 21 Feb 2007 16:50:58 -0800
- Client request/response meta data treatment for in-protocol
getResource()
Issue: Only a limited subset of the standard HTTP headers are
represented directly in our protocol. Others currently can only be
passed via extensions. Claim is its more common for resources to rely
on more then the limited subset and hence a greater chance for interop
issues.
Proposal: Add ability to pass extra request/response meta data
formally in our protocol (see Rich's writeup).
Impact: Significant change to 2.0 but is covered by a public review
comment so making this change only requires a 15 day review.
(Mike's) Analysis: Though clearly some use cases will be impacted its
unclear how many as the significant standard headers are represented in
the protocol already. It would be viable though maybe not optimal to
solve this with a post 2.0 extension/roll into a 2.1 maintenance
release earmarked to sync for JSR 286.
- Client resource caching when using in-protocol getResource()
Issue: In-protocol resources aren't cacheable (to any real extent)
because the possibility that the getResource() call might encode a
PortletURL causes the resourceURL to carry current navState of all
elements on the page. Hence cacheability is tied to this combination
of navState.
Proposal: Suggested solution adds tokens in ResourceURL to control
whether encoding is needed. Alternative is to prohibit encoding
PortletURLs in resources.
Impact: Significant change to 2.0 but is covered by a public review
comment so making a change only requires a 15 day review.
(Mike's) Analysis: Specification doesn't say anything about requiring
in-protocol getResource to support PortletURLs in the same way spec
doesn't say anything with regard to http proxy resource URLs. So could
leave this as an implementation choice and then clarify/fix in a
maintenance release or 2.1 (tied to sync with JSR 286). Problem
doesn't seem to be limited to just PortletURLs. In protocol
getResource demands the current portlet NavState be provided so at a
minimum we seem to limit caching to the current portlet navState even
for resources not based on this navState.
- Rewriting cookies
Issue: Cookies are used as a mechanism to transfer/maintain state
between the client and the web application. In the portlet environment
this technique isn't available because consumers aren't required to
proxy/rewrite portlet cookies so they can be transferred to the
client. Hence implementations/use cases that depend on this technique
have to rewrite themselves to run in a portlet environment.
Proposal: Require at some level that consumer's rewrite/proxy cookies
to the client.
Impact: This would be a significant change to the spec and because
there isn't an existing Public review comment would require a 60 day
review.
(Mike's) Analysis: We don't currently have a clear proposal for
supporting this that accounts for retaining the portlet cookie
information that is overwritten by the consumer. It may take us some
time to find an agreeable solution/compromise.
- Extensible UpdateResponse:
Issue: We decide sometime back not to make UpdateResponse extensible
as structures that enclosed it were extensible. JSR 286 may be
planning some behaviors that might best be represented as an extension
in UpdateResponse.
Proposal: Make UpdateResponse extensible
Impact: This would be a significant change to 2.0 and because it isn't
covered by an existing public review comment would require a 60 day
review.
(Mike's) Analysis: none, really ... Richard's e-mail didn't provide
details on the specific JSR 286 use where this was the sole/logical
extension point.
- General (unspecified) JSR 286 alignment:
Issue: JSR 286 isn't complete. There are a number of issues under
discussion that if come to fruition will need changes in WSRP and/or
well defined extensions to get remote interoperability. At the moment
the specifics aren't defined.
Proposal: Delay WSRP 2.0 until these become known and incorporate.
Impact: This would be a significant change to 2.0 and because it isn't
covered by an existing public review comment would require a 60 day
review.
- JSR 286 Ajax alignment:
Issue: JSR 286 intends to define Ajax support. This is distinguished
from the above because it is a large encompassing functional area and
broadly impacts wsrp consumers. And hence can be looked at
independently from (5).
Proposal: Delay WSRP 2.0 until this is defined and then incorporate
into the spec.
Impact: This would be a significant change to 2.0 and because it isn't
covered by an existing public review comment would require a 60 day
review.
Final Analysis: A number of these issues are tied to the question of
whether 2.0 should be delayed and coupled with JSR 286. I suggest we
answer this question first. If we decide to delay then no issue on
whether items with a shorter duration should be attacked now. If we
decide not to delay but rather cover this function via extensions or a
planned 2.1/maintenance release then we need to ask if its worthwhile
to attack any of the shorter term problems before completing 2.0. In
considering this remember we currently are delayed in voting on the
spec because we must each resolve internally how to vote based on
WebCollage not providing IPR clarification -- hence there may be a
window to at least slip in changes that only require 15 day review.
Mike's vote:
I vote no on tying 2.0 to JSR 286. I vote yes on doing either a 2.1 or
update via extensions. I could go either way on incorporating (1) and
(2) into 2.0. If doable within the existing delay then I am for it (if
we get an agreement on (2). If it would extend our existing delay then
I wouldn't do them and merely roll them into 2.1/extension update.
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]