Re: [wsrp] WSRP 2.0 issues: Alignement with JSR 286

[Subbu Allamaraju <subbu@bea.com>]

A quick comment on (4) and (5) below.

I don't think the JSR 286 EG has a solution for these problems, and if 
you want to the WSRP TC to consider these problems, it will have to be 
started from the use case level.

Of course, with the bar to reopen set high, any call for reopening the 
spec needs to be justified with pros and cons.

Subbu

Stefan Hepper wrote:
> As noted in our last call there are currently some JSR 286 features 
> under discussion that are not reflected in the current WSRP 2.0 spec.
> I don't like the option of defining an extension for each of this 
> feature as it would break our nice WSRP 1.0 / JSR 168 story where you 
> could export any JSR 168 portlet as WSRP producer.
> With defining the extensions you would end up saying that you can either 
> only use a subset of JSR 286 or that the WSRP impl needs to support 
> extensions A, B, C, D.
> 
> Here the current list of JSR 286 features not reflected in WSRP 2.0:
> 
> 1. Mike's point about being able to get/set client meta data for 
> getResource
> 
> 2. support of AJAX use cases
> Currently we only have the poor-mans solution of re-using getResource 
> and pbia. I don't like this re-usage for several reasons:
> - the semantic is different when used via AJAX
> - for normal getResource calls that want to provide some gif you get 
> defacto no browser cachability in many implementations as the URL of the 
> getResource call would contain all render params (or references to them) 
> in this resource URL
> - for pbia you also need to be able to set the client meta data, like 
> for getResource
> 
> 3. support for cookies
> Allow portlets setting cookies on the response of a getResouce / pbia in 
> the AJAX case. Thus the response would need an additional field to 
> transport the cookies to the consumer so that the consumer can re-write 
> the cookie and store it on the client. On the response the portlet 
> should be able to get the cookies again. Maybe this can be included in 
> the solution for issues 1.
> 
> 4. meta data for portlet-managed custom modes
> Allow portlets to provide meta data for customer modes that from a 
> consumer point of view are equivalent to the View mode so that the 
> consumer can render decorations for these modes.
> 
> 5. meta data for next possible portlet modes
> Allow portlets to provide information on what meaningful new portlet 
> modes are from the current state so that the consumer can render the 
> appropriate decorations.
> 
> 
> Stefan
> 
> 
_______________________________________________________________________
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.