Re: [wsrp-interfaces] PublicParameters issues

[Subbu Allamaraju <subbu@bea.com>]

Few comments on the issues listed:

[1] I think we should also address the case of similar custom data with 
pbia and handleEvents requests.

There is a broader use case for public parameters. If a given feature is 
not supported by either the protocol or a producer/cosnumer 
implementation, portlet/portal developers can use this mechanism to 
influence the behavior of a portlet without having to extend the protocol.

[4] I'm not sure if there is a reason to restrict to string types. The 
feature would be more useful if we allow generic types.

I agree that properties should not be mixed up with the public params 
feature.

Subbu

Michael Freedman wrote:
> As you may remember I posted a outline proposal for this in early 
> September.  Its here 
> <http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-coord/download.php/9641/PublicParameters.html>. 
>  There was a discussion in the following coordination meeting which I 
> wasn't abel to attend.  The issues that appear at the bottom of the 
> document came from the minutes of that concall.  A number of them seem 
> to be centered around expanding this mechanism to support portlet 
> property/state ala something discussed in rev 1 and partially added 
> [though downscaled to merely support persistent properties].  I would 
> like to pick this up in tomorrows concall.  My preference is to not 
> expand the current proposal. This proposal isn't about properties its 
> about render parameters.  I.e. that ability for the consumer to augment 
> rendering, not the ability for the consumer to impact portlet state. 
>  The later is seemingly handled via the event mechanism.  
>     -Mike-