Are you trying to make the following
couple of points?
1. Managing broader scopes (shared across
more portlets/users and/or longer lived) is more complex than more limited
scopes.
-> This is always true ...
what would we be introducing that increases the issues involved or makes
them harder to manage?
2. There are differences in the roles
of the Consumer and Portlet between this and the event model.
-> I believe both of these
models have the portlet indicating interest in certain things and the Consumer
determining whether or not to supply them. In both cases, this makes the
Consumer the control point for coordination information. The current proposal
actually moves the models closer as it allows the portlet to "publish"
PP values, which it can already do for events.
Rich
Subbu Allamaraju <>
07/22/05 09:52 AM
To
cc
Subject
Re: [wsrp-interfaces] Fw:
[wsrp] Additional use cases for issue #44 (set new public params)
> If the render URL is used and they are shared parameters wouldn't
the
> consumer have to be careful in calling portlets, since it may effect
> other portlets interested in the parameter value. i.e. order and which
> portlets i.e. to update cache
> Rich -> It means that Consumers have to decode the URL before
invoking
> any portlets so that any shared PPs can be sent to all interested
portlets.
Unlike the event model, in this case, Consumers decide who the
interested parties are. From an implementation point of view, this could
mean scoping choices like (a) scoped to the current portlet, (b) scoped
to the current request, (c) scoped to the current user's session, (d)
scoped to the current user forever, and (e) scoped to some/all users.
Due to security/privacy issues, Consumers may be forced go with (a) or
(b), which is limiting the model, IMO.
Subbu
