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

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

Other then (1) I don't think any of these items should be included in 
2.0.  The bar for 2.0 should be to only reopen/fix something if its 
broken in 2.0.  I don't consider 2.0 broken if it doesn't play 
well/cleanly with JSR 286.  That being said I do think we want to play 
well with 286 and maybe should consider a maintanence release of 2.0 
(i.e. 2.1) to update 2.0 with only those features that make 286 support 
clean.  But even in this case I am wary of including (2) -- Ajax support 
as a see this being a rats nest lowering my confidence we will not have 
to tweak it a few times to get it right once clients start using it -- 
and hence needs the nimbleness of an Extension.

Some specific comments:
(2) Ajax support:  you don't give hints on your ideas for a rich man's 
solution but reading between the lines it either adds more extensions 
(to be used with the other calls) or new methods to handle fragments 
specifically.  I don't think we should go there yet.  I am not convinced 
that our extension in pbia can't satisfy all your needs. 

(3) Support for cookies -- though related to (1) the question is whether 
we need/can add language to the consumer demanding cookie rewritting and 
that cookies are returned to the client.  As we get more client-centric 
implementations using cookies to carry/manage portlet state seems like 
another trick in the bag for those portlets focused on http 
client/consumer transport.
    -Mike-

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
>
>