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

[Subbu Allamaraju <subbu@bea.com>]

Some comments.

a. The use case has merits, but the questions are about the 
implementation path. This use case is a subset of a broader set of use 
cases for portlets to share context within some scopes defined by the 
consumer. For most of us, the current implementation path raises 
questions. I'm also concerned about limiting future solutions for the 
broader set of problems.

b. Obfuscation is possible with consumer rewriting, but not with 
producer writing.

c. getResource is a good point, and needs consideration for V2.

d. In a sense, we are overloading public parameters, but I don't think 
it is wrong to do so. I disagree with Mike here. There is no need to 
invent yet another means to carry data across parameters if and when we 
agree on portlet-influenced data sharing whether through URLs or some 
other means.

Subbu

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
>