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: WSRP 2.0 issues: Alignement with JSR 286

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.


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