wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Additional use cases for issue #44 (set new public params)
- From: Rich Thompson <richt2@us.ibm.com>
- To: WSRP TC <wsrp@lists.oasis-open.org>
- Date: Thu, 16 Jun 2005 06:53:01 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]