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

[Stefan Hepper <sthepper@hursley.ibm.com>]

Based on Rich's note I think there is a fundamental decision we need to 
make in the AJAX field. I don't think we can give out 2.0 and tell 
people the only mechanism you have for leveraging AJAX is via 
getResource and thus people would start using gR together with XHR and 
then in the next rev we say now that we have XPR you should always use 
XPR even for the cases where you would have previously used XHR. That 
seems wrong to me, especially if we are convinced today that you should 
always use XPR.
So for me one important part would be to make clear how we recommend 
using gR.


Michael Freedman wrote:
> 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.

One solution would be to only allow action and render URLs as fragment 
URLs and that an action fragment URL triggers a pbia, whereas a render 
fragment URL triggers a gM with the caveat that you could not change 
current nav state. This render fragment URL would replace the gR AJAX 
usage that we currently have.

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

I would not require cookie re-writting, but allow cookie re-writting.

Stefan


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