Re: [wsrp] Portlets setting Public Parameters

[Rich Thompson <richt2@us.ibm.com>]

My thoughts:

1. I have been expecting coordination
via public parameters to be an optional Consumer feature, much like events.
2. When a URL sets public parameters,
I think some requirement on the Consumer is in order such that the user
is likely to get what they have requested. I suspect this can be limited
to providing the public parameters for the duration of this user interaction
and we should include recognition that some public parameters might not
be settable by the End-User (i.e. Consumer implements access control).
3. It probably is also valuable to require
any public parameters returned from action or event processing also be
distributed for at least the scope of the user interaction as this keeps
portlets from double encoding the information in PPs and navState. 

Having typed these thoughts, this approach
ends up requiring public parameter support at a user interaction scope
with support for longer-lived scopes (e.g. user session) being a Consumer
option. Do others think this is a reasonable approach?

Rich

Michael Freedman <michael.freedman@oracle.com>

07/21/05 06:31 PM

To	wsrp <wsrp@lists.oasis-open.org>
cc
Subject	[wsrp] Portlets setting Public Parameters

For those in the camp that want to add this feature
-- do you intend we 
add language to the spec much like we have for events that indicate 
Public Parameters is an optional consumer feature and hence the portlet
can't count on receiving this value in the future?  Or are you also
interested in making this a required consumer feature to ensure intended
behavior?
     -Mike-


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php