[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44(set new public params)
Good question. I don't remember discussing the question of scoping at
the time the use case was brought up. It seems that the scoping of
changes to atleast one user interaction was a consequence of how the
proposal was addressing communication of state changes to the consumer.
One of the use cases for broader sharing is to allow a consumer managed
shared context for data - very much like a few portlets in a group
sharing session state.
Subbu
Rich Thompson wrote:
>
> I think it might be time to pull this discussion back out of the
> abstract space and relook at the use cases we have accepted as compelling.
>
> Stefan & Richard have posted some use cases that clearly would benefit
> from PPs being settable on URLs and need a PP scope of at least the user
> interaction ... including all portlets accessed during the processing of
> the user interaction. Could you post use cases requiring broader scopes?
> I presume that if we find them compelling, my answer to Mike's previous
> inquiry about requiring Consumers to support PPs may need to change.
>
> Rich
>
>
> *Subbu Allamaraju <subbu@bea.com>*
>
> 07/25/05 09:06 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)
>
>
>
>
>
>
>
>
> Stefan,
>
> This is question of scoping.
>
> As we have been debating, there are two options to let portlets update
> some shared state (public params). The first option is to let portlets
> encode such change in URLs, and the second is to let producers return
> new public params within SOAP.
>
> Apart from the encoding rules, these options influence scoping of this
> shared state that consumers can implement. If you go with the first
> option, consumers will have to limit this shared state to a user's
> session or just a few portlets on a given page. IMO, this is restrictive.
>
> However, if you go with the second option, consumer has more choice.
> Consumers can implement wider scoping of this shared state.
>
> Subbu
>
>
> Stefan Hepper wrote:
> > I think this is mixing sematics. Anything that requires a pbia is ment
> > to be a resource state change. For resource changes you need a blocking
> > semantic. Navigational state and public params in my mind define the
> > view state of the portlet and changing this state does not require a
> > pbia nor a non-blocking action. The new parameters or state can just be
> > provided to the portlet.
> >
> > This also relates to the W3C standard about GET and POST:
> >
> > " * Use GET if:
> > o The interaction is more like a question (i.e., it is a safe
> > operation such as a query, read operation, or lookup).
> > * Use POST if:
> > o The interaction is more like an order, or
> > o The interaction changes the state of the resource in a way
> > that the user would perceive (e.g., a subscription to a service), or
> > o The user be held accountable for the results of the
> > interaction."
> >
> > I don't see why it is necessary to pay the penalty of an action for
> > changing PPs.
> >
> > Stefan
> >
> >
> >
> > Subbu Allamaraju wrote:
> > > Rich Thompson wrote:
> > >
> > >>
> > >> My comment was that requiring action processing is always possible,
> > >> but why would we require it in this case and not for
> > >> mode/windowState/navState changes?
> > >
> > >
> > > I agree, but the difference is the encoding rules.
> > >
> > > Subbu
> > >
> > >>
> > >> Rich
> > >>
> > >>
> > >> *Subbu Allamaraju <subbu@bea.com>*
> > >>
> > >> 07/22/05 09:48 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)
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Thinking aloud, can't we map render URL use cases to use pbia? The
> > >> reason for changing the value of a paramter could be the result of a
> > >> user interaction, which can then compute new values and return with
> > pbia
> > >> response.
> > >>
> > >> Subbu
> > >>
> > >>
> > >> Rich Thompson wrote:
> > >> >
> > >> > It is possible to drive every style of update through action
> > >> processing,
> > >> > but I think that short changes the advantages of using render URLs
> > >> where
> > >> > they are appropriate.
> > >> >
> > >> > New navState can be specified on each URL (including render
> > URLs), why
> > >> > should not the Portlet be able to specify the shared version
> (PPs)?
> > >> >
> > >> > Rich
> > >> >
> > >> >
> > >> > *"Andre Kramer" <andre.kramer@eu.citrix.com>*
> > >> >
> > >> > 07/22/05 08:02 AM
> > >> >
> > >> > > To
> > >> > Rich Thompson/Watson/IBM@IBMUS,
> > >> <wsrp-interfaces@lists.oasis-open.org>
> > >> > cc
> > >> > > Subject
> > >> > RE: [wsrp-interfaces] Fw: [wsrp] Additional use
> > >> cases for issue #44
> > >> > (set new public params)
> > >> >
> > >> >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > After reading your previous email, I was driving towards a similar
> > >> > recommendation for Portlets to “re-fresh” public parameters by
> > >> return on
> > >> > each WSRP interaction so that a consumer is more likely to forward
> > >> > values that have been recently actively returned and I agree this
> > >> means
> > >> > Portlets have to maintain/store public param values e.g. in
> > >> navigational
> > >> > state. But, with such advice, I see no reason to have public
> > >> parameters
> > >> > to visibly appear on URLs (rewrite expressions or templates) at
> > >> all. Why
> > >> > introduce a new encoding and (in markup) transport mechanism
> when it
> > >> > seems a preferable Web Service (in SOAP response) encoding and
> > >> transport
> > >> > is already available and recommended?
> > >> > > Regards,
> > >> > Andre
> > >> > >
> > >> >
> > >>
> > ------------------------------------------------------------------------
> > >> >
> > >> > *From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> > >> > Sent:* 22 July 2005 12:24*
> > >> > To:* wsrp-interfaces@lists.oasis-open.org*
> > >> > Subject:* Re: [wsrp-interfaces] Fw: [wsrp] Additional use
> cases for
> > >> > issue #44 (set new public params)
> > >> > >
> > >> > 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
> > >> >
> > >>
> > >>
> > >
> > >
> >
> >
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]