Are you just saying that the URL encoding/decoding
rules are complex? I ask because I do not see the relationship between
this and making scoping choices. Once the information has been decoded,
I see no difference between dealing with it early in the URL processing
(i.e. before any portlet invocations) and later (after action/event processing).
As to decoding complexity, I think the
steps are straight forward:
1. Extract the parameter setting PPs
from the URL
2. Extract the value for this parameter
3. URL decode the value
4. Parse the resulting string as if
it were a querystring (hopefully using an existing utility method)
5. Step through the resulting array
of PPs and deserialize the values. Even for simple types, this may involve
conversions such as string-> int, but definitely could be more involved
for complex types the Consumer chooses to deserialize (as opposed to simply
treating in the XML serialized form and always receiving/forwarding the
XML without processing it).
Rich
Subbu Allamaraju <>
07/22/05 10:37 AM
To
cc
Subject
Re: [wsrp-interfaces] Fw:
[wsrp] Additional use cases for issue #44 (set new public params)
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
>
