Yes, and the beauty of this is it is exactly what we had defined until we
started down this road of shared PP names. I.e. its already defined and
done -- and we can roll onto other issues.
-Mike-
Andre Kramer wrote:
I do see the usefulness
of a limited consumer to portlet value sharing, with the consumer supplying
values for “slots” requested by a portlet with no push back by the portlet.
Anything that updates values to be held by the consumer (e.g. the shared
timezone) to me implied that the changes be propogated to the consumer’s
store and to other portlets to be useful. Maybe that is all we can support
in 2.0 (with some error feedback channel as I previously suggested).
Regards,
Andre
From: Michael Freedman [mailto:]
Sent: 27 July 2005 13:13
To:
Cc: Michael Freedman
Subject: Re: [wsrp-interfaces]
Fw: [wsrp] Additional use cases for issue #44 (set new public params)
Yes, I am in the U.K. this week enjoying the sunny
weather :-)
The base PP use case is one where the consumer wants to [in part] drive
the content the portlet produces. The simple example I used way back when
was a portlet that was locale [zip code] specific such as the weather portlet.
By publishing the PP for zip code the consumer could drive the content of
this portlet -- for example by using information from the current user's
user profile, or using a predefined [page] value, or even a value it publishes/recognizes
from URLs submitted by its clients. In each of these cases the value is
commonly request dependnent. In this base scenario the PPs are local to
a portlet [each portlet's are independent]. Coordination is established/managed
by the consumer when it decides to use the same values for PPs in differing
portlets. I.e. this mechanism allows a Consumer to coordinate with a producer.
What it doesn't do is allow one producer/portlet to coordinate with another.
We have events for this. Currently, we are discussing expanding PPs so
they can also be used as an optimization mechanism for portlet to portlet
coordination. I am okay with us doing that if we don't expand/change the
base semantics of PP [i.e. its public navigational state] and we prefer this
mechanism over a type of transient property mechanism we might add in the
future. Personally, I currently think transient properties will be the better/best
solution, once we define them and that we should wait vs. using PPs so as
not to confuse folks later by giving them too many options for doing roughly
the same thing. I don't see that our lack of support for this optimization
in 2.0 would be bad -- the function is doable via events just a little less
efficiently.
My comments on PerformInteraction were not really in relation to PPs. I
am trying to separate these some. My PerformInteraction comment suggests
rather then overload getMarkup and misshandling the definition we already
seem to have defined a mechanism that fits the purpose proposed. If so then
we should use it. When the follow-on question arises of how do I encode/do
cross portlet coordination with a performInteraction URL -- my answer looks
back to the independent decision we made above. If we decide that transient
properties is the right way to do this, then in WSRP 2.0 the answer is you
can't -- you either wait for us to add transient properties or you use a BlockingInteraction/event.
If our answer to the above is we are willing to live with the limited set
of semantics you get when you define Public Navigational state where consumers
are required to coordinate providing a consistent value when like names are
used -- then you have the support we will add for setting/encoding PPs.
-Mike-
Andre Kramer wrote:
Hi
Mike (you must be on UK
time),
Could you describe
a use case were the PP is just shared between the consumer and one portlet?
The only ones I can think of are really scenarios for a complex consumer
(also know as rich or smart client) that should be doing Web Services calls
that are application specific rather than piggy backing on a generic protocol
like WSRP.
My confusions
about the separate issues may be caused by not seeing uses that are not communicated
between portlets (what I would call shared but non-public) or not maintained
between requests (what I would call transient). PPs promised to make coordinated
values (such as current time zone communicated to multiple portlets) easier
for portlet programmers than full blown event handling but seem to require
that they be public and non-transient.
Thinking ahead,
relaxing the blocking semantics of actions would help but would this not
take the event handling communication round out of such interactions hence
forcing (or encouraging depending on viewpoint) use of PPs? I think I would
rather encourage use of events and discourage PPs.
Regards,
Andre
From: Michael Freedman [mailto:]
Sent: 27 July 2005 09:42
To:
Cc: Michael Freedman
Subject: Re: [wsrp-interfaces]
Fw: [wsrp] Additional use cases for issue #44 (set new public params)
How did we take two separate discussions/issues,
fuse them into one and make the resulting discussion even more cloudy?
Anyway, on PP let's get back to basics.
Didn't we decide a few weeks back that we were not going to design/describe
transient properties in this realease?
Didn't we decide that PP were a separate concept from transient properties?
And that the distinction between the two is that PP is public navigational
state with no defined consumer scope while transient properties are consumer
managed state with defined scope?
And don't we define public navigational state semantics as equivalent to
regular navigational state semantics except that the value is not opaque
to the consumer?
So isn't the only issue here whether the use cases Stephan and Richard have
given us are reasonable/preferrable to solve via PP [as compared to using
either events or the to be designed transient properties]?
If so, here are my comments...I think we need to compare constrast supporting
these use cases with PP vs transient properties. PP doesn't introduce any
notion of shared state -- each portlets navigational state is its own. Transient
properties will likely support a notion of shared state. Yes, we can add
some conventions to PP to require the consumer to associate PPs with the
same name meaning they should receive the same values -- and this is what
we have suggested we use to support the use cases. If we want this semantics
then, yes we need to offer equivalent mechanisms to the portlet to set public
navigational state as we do regular navigational state. I think Rich's proposal
does this. If we end up thinking that once we have transient properties
it will make more sense to support these use case with them [since the scope
of sharing will likely be defined/influenced by the portlets] then I would
suggest it might be better if we didn't add this behavior to PPs and merely
leave them restricted to the defining portlet. If we choose this later approach
then we don't need any way for the portlet to set PPs as setting regular
navigational state should suffice. [And remember, the use cases are supportable
in 2.0 via events while we wait for a more efficient mechanism in 3.0].
As for supporting method GET for render URLs, as I said last week, it seems
what is being proposed here is exactly what performInteraction was all about.
Why isn't this merely a proposal that we add performInteraction back into
the specification? Rich, can you dust off the old performInteraction description
and send it out to folks so we can see if we already have a completely designed
and if I recall agreed upon set of semantics?
-Mike-
Rich Thompson wrote:
I'm sorry, but I find the whole
SOAP vs REST debate irrelevant to this discussion.
There are some key questions
though:
1. Does the semantics of getMarkup
match that of HTTP GET so that Consumers can use GET for render links?
If the answer to #1 is yes
(I think it is), then:
2. If PPs are added to URLs,
can the Consumer support them for the scope of the user interaction across
all portlets on the page without violating HTTP GET semantics?
3. If PPs are added to URLs,
can the Consumer support them for a scope encompassing multiple user interactions
across all portlets interacted with and not violate HTTP GET semantics?
I think the answer to all three
questions is yes, though #3 requires the Consumer to support PPs as part
of its own navigation state. Common web usage would also allow storing the
PPs in a user session, though technically this would violate GET semantics
as it is an update of server-side state.
Rich
"Andre
Kramer" <>
07/26/05 10:05 AM
To
Rich Thompson/Watson/IBM@IBMUS,
<>
cc
Subject
RE: [wsrp-interfaces] Fw:
[wsrp] Additional use cases for issue #44 (set new public params)
But surely the
(if any) desire is to enable GET semantics between the browser and the consumer
Portal for optimized “render” interactions? All WSRP operations today use
SOAP (and therefore POSTs) and are explicitly not REST. In any case, I would
argue for a simple developer model that supports the use cases. These, for
me, naturally require a statefull consumer to serialize updating changes
to shared public parameters or could possibly be poorly supported by a set-for-one-interaction
/one-shot imposed limitation. I don’t particularly wish to go down the “Web
GET/POST semantics” rat hole for WSRP just for such a limitation.
Regards,
Andre
From: Rich Thompson [mailto:]
Sent: 26 July 2005 14:15
To:
Subject: RE: [wsrp-interfaces] Fw: [wsrp] Additional use cases
for issue #44 (set new public params)
I can definitely see useful coordination happening without the reversion
you describe if the Consumer chooses to treat PPs as part of the Consumer's
navigational state. This keeps it from impacting state managed server-side
(i.e. is compatible with GET semantics) while enabling ongoing, state-oriented
coordination of the portlets being rendered for the user (i.e. once the zipcode
PP is set, it stays at that value until it is reset by some other user/Consumer/portlet
action).
Rich
"Andre
Kramer" <>
07/25/05 10:43 AM
To
Rich Thompson/Watson/IBM@IBMUS,
<>
cc
Subject
RE: [wsrp-interfaces] Fw:
[wsrp] Additional use cases for issue #44 (set new public params)
Could Stefan & Richard please remind us as to when it is useful to have
a render URL affect other portlets on a page (just) for the duration of one
page fetch, when a subsequent refresh (browser button) is likely to revert
to the previous consumer state (as nothing permanent is being implied spanning
consumer/portlets)?
I suspect any useful coordination state change seems more related to a consumer
effectively tracking and forwarding shared values and so the Web request
to the consumer should itself be a POST to the consumer/Portal? Given PPs
on render URLs that don’t last v.s. PPs in action replies that do (SHOULD/MUST)
aren’t developers going to choose actions anyway, e.g. updating a charting
page’s units from imperial to metric?
Regards,
Andre
From: Rich Thompson [mailto:]
Sent: 25 July 2005 15:02
To:
Subject: Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases
for issue #44 (set new public params)
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
<>
07/25/05 09:06 AM
To
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 <>*
> >>
> >> 07/22/05 09:48 AM
> >>
> >>
> >> To
> >>
> >> 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" <>*
> >> >
> >> > 07/22/05 08:02 AM
> >> >
> >> > > To
> >> > Rich Thompson/Watson/IBM@IBMUS,
> >> <>
> >> > 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:] *
> >> > Sent:* 22 July 2005 12:24*
> >> > To:* *
> >> > 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
> >> >
> >> > 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
> >> <>
> >> > 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 <>*
> >> >
> >> > 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
> >> >
> >>
> >>
> >
> >
>
>
