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

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

I agree that there are subtle differences
in the issues between setting PPs on URLs and pbia, but would first comment
that we have already decided that scoping is entirely under the control
of the Consumer. Portlets indicate interest in shared values and (if this
proposal is approved) can offer shared values to the Consumer's environment.

Why would it be harder for the Consumer
to access a multi-user scope when processing render URLs than when processing
action URLs?

I agree that multi-user scopes have
additional issues, but not why any of these are protocol issues.

I doubt Portlets would place items with
security concerns on URLs. We may want to discuss whether to discourage
these ever being exposed as PPs since a stateless Consumer is likely to
push them out to the end-user agent in one manner or another (URL or cookie).

Rich

Subbu Allamaraju <subbu@bea.com>

07/22/05 09:44 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)

I see more value in this proposal than the current
model for public 
parameters. But I would like to split the discussion into two.

a. Encoding public parameters in URLs.

b. Returning public parameters with pbia

Each of these approaches have their merits.

Pros of (a):

- Support PP encoding in render URLs

Cons of (a):

- Scope: While it may be theoretically possible for the consumer to 
share those values for other users, it will be hard.

- Pivacy and security: Unlike navState, this state is not opaque. We 
need to account for that. This will be one reason for Consumer's to not
share those public params across other users' interactions.

- Encoding: Awkward for complex types.

Pros of (b):

- Data not visible to users

- Broader scope for sharing public parameters. Consumer can choose.

- Can act as a shared context

Cons of (b):

- Need to return new parameters along with pbia response. We may allow
getMarkup to return new values, but it may prevent consumer's to store
public parameters on the client.

Since both approaches allow portlets to specify new parameters/values,
we also need to have a notion of scope. Portlets can then have a say of
whether a parameter can be shared or not (e.g. perUser, perGroup etc.).

Regards,

Subbu

Rich Thompson wrote:
> 
> The Interfaces SC discussion raised the question about the scope of
PPs 
> set in this manner. Namely; does the Portlet need to keep specifying
the 
> PPs on all subsequent requests or can it depend on the Consumer to
> resupply those values in the future (i.e. some scope, like user-session,
> becomes mandated).
> 
> I think we should be careful to leave scoping questions up to the
> Consumer, but if PPs are to function as a coordination model, then
we 
> also have to discourage Portlets from setting all PPs on every URL.
A 
> model where Portlets are encouraged to store current PP values 
> (preferably in navState) for use as default values should the Consumer
> not supply a value on a subsequent invocation and only do PP setting
> when a value needs to change accomplishes this. It removes setting
the 
> value each time such that coordination happens in a more reasonable
> manner while also providing for reasonable user experience, even when
> the Consumer does not support and PP scope beyond the user interaction.
> 
> Note: We could consider a model where Portlets MUST encode all PPs
on 
> all URLs such that this supplies the scope, rather than the Consumer
> determining the scope, but that this fails as the Portlet might not
have 
> access to all PPs (security and privacy reasons).
> 
> Rich
> 
> 
> *Rich Thompson/Watson/IBM@IBMUS*
> 
> 07/07/05 11:54 AM
> 
>                  
> To
>                  wsrp-interfaces@lists.oasis-open.org
> cc
>                  
> Subject
>                  [wsrp-interfaces]
Fw: [wsrp] Additional use cases for issue #44 (set 
> new public params)
> 
> 
>                  
> 
> 
> 
> 
> 
> 
> Reposting, as requested ...
> ----- Forwarded by Rich Thompson/Watson/IBM on 07/07/05 11:52 AM -----
>                  *Rich
Thompson/Watson/IBM@IBMUS*
> 
> 06/15/05 09:24 AM
> 
>                  
      
>        To:        WSRP TC
<wsrp@lists.oasis-open.org>
>        cc:        
>        Subject:        Re:
[wsrp] Additional use cases for issue #44 
> (set new public params)
> 
> 
> 
> 
> 
> 
> I had taken a to-do from the Interfaces SC to develop (in conjunction
> with Stefan, Richard and Mike) a proposal for this portion of Issue
#44. 
> Here is that proposal: *_
> 
> Philosophy:_* Since Public Parameters (PP) are another aspect of 
> Consumer managed state that is exposed to Portlets (the other two
are 
> modes and windowState), Portlets should be able to request changes
to 
> PPs in much the same way as they do modes and windowStates (on URLs
and 
> in responses from pbia and handleEvents). *_
> 
> On URLs: (2 issues)_*
> 1. Need to encode 3 pieces of information (request to set a PP, the
> PPname and the PPvalue) into 2 places (name=value) when using a 
> querystring and deal with the reduced set of characters allowed in
the 
> path portion ('=' is not allowed). Templates also introduce an issue
> with how to encode multiple PPs ... preferably with the Template only
> having a single placeholder.
> -Proposal:
> 1. All public parameters specified on a URL are concatenated in the
form 
> of "PPname1=PPvalue1&PPname2=PPvalue2".
> 2. The resulting string is URL encoded (changes '=' into %3D and '&'
> into %26) to make it valid in both the querystring and path portions
of 
> a URL.
> 3. This URL encoded string becomes the value for the 
> wsrp-publicParameter URL parameter, regardless of whether template
> processing or Consumer URL rewriting is in use.
> 
> 2. How to encode complex PPvalues? I suggest serializing the PPvalue
to 
> XML and URL encoding this XML. The Consumer would then receive the
PP, 
> recognize it is of a complex type (based on PPname) and decode the
> PPvalue to get the XML. *_
> 
> On Operation responses:_*
> 1. Return PP requests via a field much as newMode and newWindowState
> request updates to those aspects of Consumer managed state. Suggest
this 
> field be of type QNamedStringArray, though it could be an array of
> NamedString if we do not want to introduce a usage of a type from
the 
> 'extra' namespace.
> 
> Rich
> *Michael Freedman <michael.freedman@oracle.com>*
> 
> 05/24/05 07:55 PM
> 
>                  
> To
>                  WSRP
TC <wsrp@lists.oasis-open.org>
> cc
>                  
> Subject
>                  Re:
[wsrp] Additional use cases for issue #44 (set new public params)
> 
> 
> 
> 
>                  
> 
> 
> 
> 
> 
> 
> 
> I too am interested in hearing people's current opinions.  Our
early 
> coordination discussions considered this carefully.  It was decided
at 
> that time to not support two coordination models that delivered 
> equivalent function.  Though I pushed strongly for such a parameter
> style mechanism, the subcomittee preferred Events because it not only
> allowed state to be transferred but also actions.  The current
public 
> parameter model was introduced by me later and was crafted specifically
> to not step on the the toes of Events.  
> 
> To extend this conversation I would like to pose:
> 1.        We consider whether publicParameters
should be QNames so they 
> can be shared/reused across producers.  Note: this is likely
needed 
> whether we stick with events or add the ability to encode a public
> parameter directly in the URL.
> 2.        We consider adding a new "defined
event" called 
> publicParameterValueChanged.  The payload of this event would
be the 
> QName of the parameter and an Object any holding the parmeter value
> [though it might be nice to support our Any/String optional pair style
> here].
> 3.        We consider defining the meaning of
publicParameter whose 
> capability contains the value "required" as meaning that
normal usage of 
> this portlet requires the consumer to provide this value.  The
portlet 
> would still have to deal with situations in which this wasn't provided
> but likely an end-user would consider this usage crufty/abnormal.
 For 
> example if a portlet required a CustID parameter and didn't receive
one 
> it could display a view that asks for a custID.  The key here
by saying 
> "required" [we can choose a different capability name] the
consumer can 
> distinguish between those public parameters that have a secondary
impact 
> on the portlet [optional] and those that have a primary or important
> impact [required].
>  -Mike-
> 
> Stefan Hepper wrote:
> Hi,
> I've some use cases that may be a good match for the ability to set
new 
> public parameters by the producer and to encode public parameters
in 
> URls by the producer.
> 
> 1. displaying content based on a specific product id:
> - Portlet A allows to select a product from a list
> - User clicks on a specific product
> - Portlet B renders details of this product
> - Portlet C renders currently available number of items on stock for
> this product
> - user wants to bookmark this result in order to come back to product
> tomorrow
> 
> implementation with events:
> Portlet A encodes the customer selection URLs as POST action links
> Portlet A receives a performBlockingInteraction call
> Portlet A returns event productID=10
> Portlet B receive a blocking handleEvents call for productID=10 and
> returns new navigational state
> Portlet C receive a blocking handleEvents call for productID=10 and
> returns new navigational state
> 
> implementation with public params:
> Portlet A encodes the product selection URLs as GET render links with
> the productID as public param
> Portlet A receives a render call with the public param productID=10
> Portlet B receives a render call with the public param productID=10
> Portlet C receives a render call with the public param productID=10
> 
> which would be much more efficient and also consistent with the W3C
> architecture as links that do only change view state should be encoded
> as GET links.
> 
> 
> 2. display content based on a specific customer id
> 
> 3. display content based on the selected state of a map
> portlet A displays a map of USA
> portlet B displays information on the selected state (# people 
> registered, capital, ...)
> portlet C displays all IBM labs in that state
> 
> and many more.
> 
> 
> This would allow to have some gobal navigational state that can be
set 
> via URLs by portlets. Also portlets may want to set new public params
as 
> a result of an blocking interaction or a handle event call.
> 
> 
> What do you think?
> 
> 
> Stefan
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your
TCs in 
> OASIS
> at: _
> __https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
> 
> ---------------------------------------------------------------------
To 
> unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs
in 
> OASIS at: 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php