I take it the 10% you are talking about
is the ability to define and set the value of an arbitrary PP "on-the-fly".
I think that changes the semantics from "Consumer managed" to
"Consumer hosted". There are a lot of places in the architecture
of systems where that makes sense, but I am not sure this is one of them.
We may need to more explicitly distinguish this coordination model from
such a session model.
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.
Rich
"Yossi Tamari"
<>
06/15/05 12:45 PM
To
"WSRP TC" <>
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:]
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"
<>
06/15/05 12:10 PM
To
"WSRP TC"
<>
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:]
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 <>
06/15/05 11:51 AM
To
Rich Thompson/Watson/IBM@IBMUS
cc
WSRP TC <>
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" <>*
>
> 06/15/05 11:15 AM
>
>
> To
> Rich
Thompson/Watson/IBM@IBMUS, "WSRP TC" <>
> 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:] *
> 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" <>*
>
> 06/15/05 09:35 AM
>
>
> To
> Rich
Thompson/Watson/IBM@IBMUS, "WSRP TC" <>
> 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:] *
> 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 <>*
>
> 05/24/05 07:55 PM
>
>
>
>
> To
> WSRP
TC <>
> 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
