My point is URL-encoding style makes it harder for consumers to make
broader scoping choices.
Subbu
Rich Thompson wrote:
>
> 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
>
