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

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

I agree that the current definition
of PP is that of Consumer managed state which is supplied to Portlets on
each operation invocation. People have raised objections to the arbitrary
boundary that is currently drawn, which stops Portlets from having any
influence on the value or scope of such state. I am beginning to suspect
that the current definition is so limited that Portlet developers will
find it mostly unusable. My question is whether a different approach (which
does not use the concept of Consumer managed state) can solve the limited
set of use cases we have accepted for v2 without starting down a path we
have decided to not fully (and maybe not even reasonably) develop for v2.

Changing to a model where PPs are an
interface to influence navState wouldn't stop Portlets from actually using
the state in other manners, but would clearly define how the Consumer is
managing that portion of the overall state; namely, once the Portlet has
an opportunity to store PP values within its navState (i.e. a pbia or handleEvents
invocation), then the Consumer is free to stop supplying that value to
the Portlet as it is now the Portlet's responsibility to handle that bit
of state. Since the Portlet is not allowed to store state on a getMarkup
invocation, the Consumer would need to continue sending a particular PP
for as long as the Portlet receives it just on getMarkup invocations. This
involves per Portlet storage on the Consumer (at least a dirty bit) and
may have other downsides that would cause us to not want to consider it,
but I am interested in everyone's thoughts. 

Rich

Subbu Allamaraju <subbu@bea.com>

07/29/05 12:42 AM

To
cc	wsrp-interfaces@lists.oasis-open.org
Subject	Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44 (set new public params)

My reading of the spec/feature is that public parameters
is just 
consumer managed state that portlets can make use of during various 
operations. It would be limiting to tie public parameters to nav state
because they (can) get used for altogether different purposes, and so we
should avoid any language to imply that. This kind of interpretation is
possible, but it seems artificial.

Subbu

Rich Thompson wrote:
> 
> I agree that the overlap with navState means that PPs which are only
> sent back to the portlet that originated them would be redundant.
> However, my understanding of the basic premise behind the current
draft 
> for PPs is that the Portlet is making a portion of its navState public
> such that the Consumer can coordinate that public portion of its 
> navState with the public portion of the navState of other Portlets.
For 
> the Portlet to lose all input relative to that portion of its navState
> is a bit of a high price to pay for choosing to make it public.
> 
> Of course another model for this would be that PPs become a 
> property-oriented means to impact a Portlet's navState (i.e. PP becomes
> more of an interface than a state model). In this case Portlets always
> represent the current value within their navState and values passed
via 
> PPs simply provides another means to set values within their navState.
> This is not what is currently drafted for PPs, but would be a reasonable
> change. Even in this model, I would argue that when a Portlet generates
> a URL which impacts a portion of its navState which has been exposed
via 
> PPs, it makes more sense, from a coordination point of view, for the
> update to flow through PPs such that it can also provide an update
to 
> any other Portlets where the Consumer has mapped the same PP.
> 
> Having typed this alternative, I think I like the way it removes issues
> regarding Consumer storage of PP. A Consumer implementation could
to 
> have a PP store like we have been articulating, but it could also
simply 
> define a particular wiring for values to flow as they become available
> to the Consumer and thereby provide the coordination aspects without
> actually storing the values sent to the Portlets.
> 
> Rich
> 
> 
> *Michael Freedman <michael.freedman@oracle.com>*
> 
> 07/28/05 01:42 PM
> 
>                  
> To
>                  Rich
Thompson/Watson/IBM@IBMUS
> cc
>                  wsrp-interfaces@lists.oasis-open.org
> Subject
>                  Re:
[wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44 
> (set new public params)
> 
> 
>                  
> 
> 
> 
> 
> 
> On why to disallow the portlet -- my comment was if PPs only apply
to 
> the given portlet then the portlet can use Navigational State instead
to 
> perform the same function when setting itself in an URL. I don't 
> understand your comment at the end saying this doesn't solve the use
> case of a portlet wanting to affect the value of its subsequent render
[ 
> though I do understand how it prevents the sharing use case]. I do
> however agree this is a little artificial/unnatural but point it out
as 
> a way of further narrowing/simplifying PP semantics so that they don't
> clash with transient properties when we add them in the future.  
>    -Mike-
> 
> Rich Thompson wrote:
> 
> To your questions:
> 
> Simply because the user can drive the coordination does not mean the
> user is editing a URL. If the user has chosen to activate a URL which
> sets a PP, then the user is driving the coordination. The Consumer
can 
> certainly generate such a URL for the user to interact with. Why 
> disallow the Portlet also being able to generate such a URL? Stefan's
> use cases certainly make a case for allowing it.
> 
> Obfuscation does enter the picture, nor does by reference questions.
If 
> the Consumer has particular encodings, including using by reference,
> then such issues are taken care of when the Consumer rewrites the
URL.
> 
> WSRP involves the Consumer due to issues with the network topology
and 
> access to resources which are behind firewalls. This proposal impacts
> none of that reasoning nor alters choices already made.
> 
> If you are questioning whether PPs ought to be supplied on getResource
> invocations, I would consider that an orthogonal question. One we
should 
> definitely address, but orthogonal to the issue at hand.
> 
> Again, look back at Stefan's use cases to see that this is not 
> overloading PPs, but rather allowing Portlets to have an influence
on PP 
> values. Limiting the interaction to the Portlet which generates the
URL 
> (e.g. using navState or some new facility like portlet_querystring)
> doesn't solve the use case.
> 
> Rich
> 
> *"Andre Kramer" **_<andre.kramer@eu.citrix.com>_*
> <mailto:andre.kramer@eu.citrix.com>
> 
> 07/28/05 04:43 AM
> 
>                  
> To
>                  Rich
Thompson/Watson/IBM@IBMUS, 
> _<wsrp-interfaces@lists.oasis-open.org>_ 
> <mailto:wsrp-interfaces@lists.oasis-open.org>
> cc
>                  
> Subject
>                  RE:
[wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44 
> (set new public params)
> 
> 
> 
>                  
> 
> 
> 
> 
> 
> 
> Do you expect end users to edit URLs to override consumer (PP) settings?
> Then I would ask (to prime the call today):
>  
> -          Is such editing of URLs desirable?
Allowed for Web experts 
> for simple URLs, I agree, but for Portlets?
> -          Are URLs not too obfuscated (encoded)
to allow manual 
> editing? Because of size limitations, the URL may be by-reference.
> -          Why need the consumer be involved?
Since user explicitly 
> submits she may not expect the consumer Portal to be in the loop.
> -          Are other types of URLs (to resources
and out-of-Portlet Web 
> content) also not to be covered?
> -          Why overload PPs with this feature?
Maybe a separate user to 
> portlet channel would be better? Something more like a query string?
>  
> My suggestion for 3.0 would be to look at having a trailing URL part
> (wsrp-portlet-query-string) that can be added to consumer produced
URLs 
> that is forwarded unmodified (or as a separate key/value list) by
the 
> consumer to explicitly model query strings if we really require and
can 
> support such a feature.
>  
> Regards,
> Andre
>  
> 
> 
> ------------------------------------------------------------------------
> 
> *
> From:* Rich Thompson [_mailto:richt2@us.ibm.com_] *
> Sent:* 27 July 2005 19:18*
> To:* _wsrp-interfaces@lists.oasis-open.org_ 
> <mailto:wsrp-interfaces@lists.oasis-open.org>*
> Subject:* Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for
> issue #44 (set new public params)
>  
> 
> To say this another way, PPs enable user/Consumer driven coordination.
> The current question is whether to allow Portlets to generate URLs
that 
> enable the user driven portion of this rather than requiring such
URLs 
> be generated by the Consumer. I think the use cases Stefan posted
say 
> there is value to allowing Portlets to generate such URLs.
> 
> Rich
> 
>