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

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

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>

07/28/05 04:43 AM

To	Rich Thompson/Watson/IBM@IBMUS, <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
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