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

[Subbu Allamaraju <subbu@bea.com>]

>
> One potential way to call out that the PP model is not a "session" 
> would be to call out the semantics of what needs to be supplied to a 
> Portlet as PPs when the Consumer does not support PPs. I would suggest 
> that any values pushed to the Consumer (either via the URL or a 
> response from pbia or handleEvents) have to be supplied to subsequent 
> invocations on the Portlet during the processing of that particular 
> user interaction. This encourages Portlets to move state changes that 
> might have been encoded in the opaque navState out to PPs.

To make this round-tripping work, the portlet must keep encoding this 
state within each URL it generates, which makes it similar to navState. 
The only difference I see is that public params would become a global 
shared state. I doubt if it is realistic to attempt to encode such state 
in URLs.

Subbu

>
> Rich
>
>
> *"Yossi Tamari" <yossi@giloventures.com>*
>
> 06/15/05 12:45 PM
>
> 	
> To
> 	"WSRP TC" <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [wsrp] Additional use cases for issue #44 (set new public params)
>
>
>
> 	
>
>
>
>
>
> What it means is that “public parameters” becomes much like a 
> “session” object (a container managed collection of properties that 
> are available at any request and can be set by the portlet).
> Two portlets on the page can then share a session-scoped property, 
> regardless of whether this property in known to the consumer. I think 
> what both Subbu and me are saying is that the changes proposed here go 
> 90% of the way to this, and users of the protocol will expect the 
> remaining 10%.
>
> Yossi.
>
> ------------------------------------------------------------------------
>
> *From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> Sent:* Wednesday, June 15, 2005 7:26 PM*
> To:* WSRP TC*
> Subject:* RE: [wsrp] Additional use cases for issue #44 (set new 
> public params)
>
>
> What would it mean for a Portlet to change a public parameter that the 
> Consumer is not aware of? Public parameters are managed at the 
> Consumer. Portlets can certainly do computations and end up using 
> values other than what the Consumer supplied, but they haven't 
> actually changed the parameter unless they tell the Consumer of the 
> change. Instead they have only manipulated and then used some internal 
> value.
>
> In other words, just because the Consumer supplies "06611" (my 
> zipcode) as the value for a public parameter called "zipcode" to a 
> weather portlet doesn't mean the portlet isn't free to display weather 
> data about some other zipcode. I, as the user, might choose to stop 
> using such a portlet, but that doesn't mean the protocol is 
> restricting the portlet to using the value as supplied.
>
> Rich
>
> *"Yossi Tamari" <yossi@giloventures.com>*
>
> 06/15/05 12:10 PM
>
> 	
> To
> 	"WSRP TC" <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [wsrp] Additional use cases for issue #44 (set new public params)
>
>
>
> 	
>
>
>
>
>
>
> … And there you said it: Public parameters have become a 
> transparent-to-the-Consumer state of the portlet, rather than the 
> transparent-to-the-Portlet state of the consumer.
>
> I just feel we need to keep these things out in the open rather than 
> try to avoid actually saying them. Because I have no doubt that the 
> next question that will be asked is what happens if the portlet 
> “changes” a public parameter that the consumer is not aware of.
>
> Yossi.
>
>
>
> ------------------------------------------------------------------------
>
> *
> From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> Sent:* Wednesday, June 15, 2005 7:03 PM*
> To:* WSRP TC*
> Subject:* Re: [wsrp] Additional use cases for issue #44 (set new 
> public params)
>
>
> I think the use case for public parameters on render URLs also relates 
> to them effectively being an extension to the opaque navState of WSRP 
> v1. One can change the opaque portion of the navState on render URLs, 
> why not the transparent-to-the-Consumer portion?
>
> Rich
>
> *Stefan Hepper <sthepper@hursley.ibm.com>*
>
> 06/15/05 11:51 AM
>
> 	
>
>
> To
> 	Rich Thompson/Watson/IBM@IBMUS
> cc
> 	WSRP TC <wsrp@lists.oasis-open.org>
> Subject
> 	Re: [wsrp] Additional use cases for issue #44 (set new public params)
>
>
>
>
> 	
>
>
>
>
>
>
> It also makes a hugh difference from the HTTP protocol point of view as
> pbia need to be implemented as HTTP POST whereas you would only need
> HTTP GETs for changing public parameters. Otherwise how could you comply
> with the W3C architecture?
> Also search engines like google very much count on this distinction in
> order to follow links.
>
> Stefan
>
> Rich Thompson wrote:
> >
> > I think the use case for any of them being on the URL is render URLs.
> > Specifying them on the URL allows such inputs while short-circuiting 
> the
> > action processing step(s) of the protocol, resulting in improved
> > cacheability and performance.
> >
> > Rich
> >
> >
> > *"Andre Kramer" <andre.kramer@eu.citrix.com>*
> >
> > 06/15/05 11:15 AM
> >
> >
> > To
> > Rich Thompson/Watson/IBM@IBMUS, "WSRP TC" <wsrp@lists.oasis-open.org>
> > cc
> >
> > Subject
> > RE: [wsrp] Additional use cases for issue #44 (set new public params)
> >
> >
> >
> >
> >
> >
> >
> >
> > I understood it to be an optimization. i.e. the consumer can indicate
> > that it is willing to accept a new window state or mode switch by
> > calling performBlockingInteraction with the values supplied on the URL.
> > I’m not convinced that’s the case for public params in general.
> >
> > -- Andre
> >
> >
> > ------------------------------------------------------------------------
> >
> > *From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> > Sent:* 15 June 2005 16:04*
> > To:* WSRP TC*
> > Subject:* RE: [wsrp] Additional use cases for issue #44 (set new public
> > params)
> >
> >
> > The use cases Stefan posted to start this thread need public parameters
> > to be set on the URL.
> >
> > Other other question I would ask is why doesn't the same argument apply
> > to mode and windowState? (i.e. I am arguing for consistency as well as
> > efficiency)
> >
> > Rich
> >
> > *"Andre Kramer" <andre.kramer@eu.citrix.com>*
> >
> > 06/15/05 09:35 AM
> >
> >
> > To
> > Rich Thompson/Watson/IBM@IBMUS, "WSRP TC" <wsrp@lists.oasis-open.org>
> > cc
> >
> > Subject
> > RE: [wsrp] Additional use cases for issue #44 (set new public params)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > I can subscribe to the philosophy of portlets requesting updates to
> > public parameters but why do they need to be able to request update via
> > markup URLs (i.e. on link activation). Surely, a much simpler model
> > would be just to let performBlockingInteraction and friends
> > return/output as well as take as input public parameters? That would 
> tie
> > into the event model better as portlets would have the chance to
> > coordinate such updates if an update was a subscribable event.
> >
> > Regards,
> > Andre
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > *
> > From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> > Sent:* 15 June 2005 14:25*
> > To:* WSRP TC*
> > 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 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
> >
>
>
>
> ---------------------------------------------------------------------
> 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
>