I think the state change for the consumer
and flowing into other portlets that take a changed public parameter as shared input
does argue for limiting public parameter changes to performBlockingInteraction
(accepting no optimization via render URLs). Then we can have a hope of sharing
such public parameter setting Portlets between users, but not the set values
which will need to be maintained per-user and without allowing end-users to communicate
or edit them. Since URLs can be cut&pasted this argues for not putting public
parameters on the URLs. i.e. Security argues for not exposing “public”
parameters in markup c.f. our discussions of encrypting navigational state in
1.0.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 16 June 2005 11:53
To: WSRP TC
Subject: Re: [wsrp] Additional use
cases for issue #44 (set new public params)
I would suspect that most situations would end up with
unexpected results if the Consumer chooses to share public parameters between
users.
Rich
Subbu Allamaraju
<subbu@bea.com>
06/15/05 08:22 PM
|
To
|
WSRP TC <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
|
Re: [wsrp] Additional use cases for issue #44
(set new public params)
|
|
Not
exactly, when we consider multiple users. When public params are
encoded within URLs, consumers will have to
extract the parameters when
the URL is activated and store them, so that those
parameters can be
supplied to various portlets for all users. This
means state change for
the consumer.
Subbu
Rich Thompson wrote:
>
> That will be true unless the current value of
PPs is pushed onto URLs.
> If the Consumer pushes the current values
onto the URLs and the
> portlet pushes new values, then idempotency
rules are not violated and
> a later activation of a render URL from a
bookmarked version of the
> page should result in similar results (i.e.
only differing by a
> dependence on session state).
>
> Rich
>
>
> *Subbu Allamaraju <subbu@bea.com>*
>
> 06/15/05 12:51 PM
>
>
> To
>
WSRP TC <wsrp@lists.oasis-open.org>
> cc
>
> Subject
>
Re: [wsrp] Additional use cases for issue #44 (set new
public params)
>
>
>
>
>
>
>
>
>
> True. But I think that the argument is a
stretch, because, by encoding
> public parameters in URLs, the portlet may be
forcing the consumer to
> update some state (for example, replace
current values with new values).
> So, this breaks idempotency rule. So, if a
portlet must update the
> consumer-managed public parameters, it should
do so via a POST and not a
> GET.
>
> Regards,
>
> Subbu
>
> Stefan Hepper wrote:
>
> > 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
> >
>
>
>
---------------------------------------------------------------------
> 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