Interfaces: WSRP 2.0 open issues

[Michael Freedman <michael.freedman@oracle.com>]

1. 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.
   
   
2. 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. 
   
   
3. 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. 
   
   
4. 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.
   
   
5. 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.
   
   
6. 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.