Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44 (setnew public params)

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

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 <subbu@bea.com>

07/22/05 10:37 AM

To	wsrp-interfaces@lists.oasis-open.org
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 <subbu@bea.com>*
> 
> 07/22/05 09:52 AM
> 
>                  
> To
>                  wsrp-interfaces@lists.oasis-open.org
> 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
>