wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Clearification: Resource URLs and markup params, etc.
- From: Rich Thompson <richt2@us.ibm.com>
- To: WSRP TC <wsrp@lists.oasis-open.org>
- Date: Tue, 21 Feb 2006 11:21:14 -0500
I agree with your general comments;
Without having spent much time reviewing this phrasing, I would think the
clarifications would look something like:
- (6.1.13 - MarkupResponse): Since the
MarkupContext structure could provide a new sessionID after the Consumer
has begun sending the page to the End-User, special handling is required
in order to not lose state related to the new session. Even for stateless
Consumers, there are techniques to properly handle this issue (e.g. HTTP
cookies).
- (6.2 - getMarkup): This operation's
semantics are that the Consumer is aggregating a page which includes the
Portlet's markup.
- (6.3 - getResource): This operation's
semantics are that the client has requested additional information in a
manner that utilized the Consumer as a proxy for supplying that information.
Rich
Subbu Allamaraju <subbu@bea.com>
02/21/06 10:12 AM
|
To
| Rich Thompson/Watson/IBM@IBMUS
|
cc
| WSRP TC <wsrp@lists.oasis-open.org>
|
Subject
| Re: [wsrp] Clearification: Resource
URLs and markup params, etc. |
|
>
> As to session, I agree that getMarkup already introduces the problem
of
> a late notification that a new session now exists. What would people
> think about adding text to 6.1.13 (MarkupResponse definition) describing
> how a stateless Consumer would need to write any new session information
> to a cookie since it is likely too late to place that information
onto
> all URLs within the page (I suppose the other option is to require
> Consumer URL rewriting and delay all rewriting until responses have
been
> received from all Portlets ... I would not favor describing this option
> in the spec)?
Instead of mentioning specific implementation choices, how about
highlighting the fact that consumers must be ready to honor sessionID
changes getMarkup and getResource so that they can provide meaningful
user experience?
> Just to not loose potential spec changes suggested so far (does this
> list miss any??):
>
> 1. Clarify difference in the semantics of getMarkup and
getResource:
> Consumer request related to page aggregation
vs client request
> related to need for additional information.
In principle, I agree, but would not want to make statements that limit
the use of getResource to static resources, or such requests to be
always driven by client requests after markup generation. The consumer
may want to pre-fetch resources.
> 2. Add sentence(s) to MarkupResponse.sessionContext (6.1.13)
> describing how a stateless Consumer can handle
such late knowledge
> of a new Portlet session.
Agreed.
> 3. 6.9/6.10 should note that HandleEventsResponse can
also return
> newMode and newWindowState (see above quote from
6.9).
Agreed.
Subbu
>
> *Richard Jacob <richard.jacob@de.ibm.com>*
>
> 02/21/06 06:04 AM
>
>
> To
> Subbu
Allamaraju <subbu@bea.com>
> cc
> WSRP
TC <wsrp@lists.oasis-open.org>
> Subject
> Re:
[wsrp] Clearification: Resource URLs and markup params, etc.
>
>
>
>
>
>
>
>
> Subbu Allamaraju <subbu@bea.com> wrote on 02/21/2006 05:50:37
AM:
>
> > > - wsrp-mode and wsrp-windowState
portlet url parameters. I would
> > > note the descriptions of these explicitly state that
they apply to
> > > render and blockingAction urlTypes. I think maintaining
the integrity
> of
> > > the aggregated page requires that these not be supported
on resource
> > > URLs, unless someone can point out how a Consumer's
decorations could
> be
> > > changed or how it would actually place a Portlet into
maximize
> > > windowState as a result of a resource URL activation.
> >
> > My interpretation is that, these parameters apply to the
portlet
> > processing the request, and not necessarily to the consumer
applying
> > decorations to the markup returned. When a URL contains
a parameter with
> > a specific window state, the consumer is merely asking
the producer to
> > generate markup or resource reflecting that window state.
I don't see a
> > requirement in the spec to change the window state or mode
of the
> > portlet, although that's what typical portal-consumers
may do.
> >
> huh?
> We explicitly say that an URL invocation of a render/pbia URL includes
the
> request to change the mode/window state.
> Therefor I would say the contrary: Consumers should honor this (or
be
> strongly advised to do so) otherwise
> the user experience will suffer. It seems strange for me to ignore
the
> request. I mean we're trying to define a common aggregated UI behavior
and
> this certainly contradicts it.
>
> > > - title: This is another
case of the Portlet having opportunity
> > > to impact the Consumer generated portion of the page
during page
> > > aggregation and therefore doesn't apply to resource
url processing
> >
> > I think, this interpretation is specific to what the consumer
is doing
> > with the markup or resource. If the consumer is aggregating
the response
> > into a page that has windows-like titlebars, it might use
the title in
> > the manner you suggest. Other usages of this field are
possible. For
> > example, a special purpose consumer may be displaying resources
in popup
> > browser windows, and use the title in the browser title
bar.
> >
> > > - sessionID: I am willing
to debate this one as I can see a
> > > number of good use cases for the Portlet returning
a new session, but
> > > how a stateless Consumer could handle it is important.
> >
> > I agree that the stateless consumer use cases break down
with sessionID
> > returned from getMarkup or getResource. As Mike points
out, we have this
> > problem with getMarkup itself.
> >
> > > In summary, perhaps we need to more explicitly state
the semantic
> > > difference between these operations. Do people generally
agree with the
>
> > > semantics I have described above? Do people have other
proposals which
> > > keep the stateless Consumer supported? Are people
willing to throw out
> > > the stateless Consumer design point statements?
> >
> > Is it impossible to keep the consumer stateless? Perhaps
not. To be
> > truely stateless, consumer can't just push various pieces
of state into
> > the markup when the page is getting generated on the server
side and
> > expect the state to ramain constant.
> I think currently they can because the render result is a result of
the
> Consumer processing. Therefor the Consumer has the control.
>
> > IMO, consumers will have to rely on
> > browser side gimmicks to support state updates that happen
after the
> > page aggregation started (with getMarkup), or even much
later (with
> > getResource).
> Well, things brings us again to AJAX style.
> But this breaks the "rule" that the Cosumer is in control
and that the page
> state is opaque/mainted by the consumer.
> Now you seem to imply that portlets/resources can manipulate the overall
> page state. I think this isn't true with what WSRP defines today and
to
> enable that we would need to drop some level of opaqueness of the
overall
> state.
>
> >
> > Subbu
> >
> > >
> > > Rich
> > >
> > >
> > > *Subbu Allamaraju <subbu@bea.com>*
> > >
> > > 02/15/06 11:48 AM
> > >
> > >
> > > To
> > > WSRP TC <wsrp@lists.oasis-open.org>
> > > cc
> > >
> > > Subject
> > > Re: [wsrp] Clearification: Resource URLs
and markup params, etc.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > The issue of a producer returning two sessionIDs in
parallel requests
> is
> > > possible, and I don't know if the spec can help either
the consumer or
> > > the producer.
> > >
> > > One way of avoiding returning new sessionIDs is to
somehow tie
> > > initCookie with sessionIDs, and raise InvalidCookie
fault when there is
> > > a need to return new sessionID. It is possible to
design a producer to
> > > tie init cookies to sessions, and never return sessionIDs.
> > >
> > > We have had a number of discussions on this topic
in the past, and the
> > > solutions are not always pretty.
> > >
> > > Subbu
> > >
> > > Stefan Hepper wrote:
> > > >
> > > > Subbu Allamaraju wrote:
> > > >> On the question of modes and states,
I don't see why a portlet
> should
> > > >> not specify mode and window state params
on a resource URL. The
> > > >> resource generated may depend on the
window state and mode.
> > > >>
> > > >> The real question is whether the mode
and window state specified in
> a
> > > >> resource URL applies to subsequent
getMarkup/pbia/he calls or not.
> > > >> The spec leaves this open. It also
leaves the same question open
> for
> > > >> normal action and render URLs.
> > > >>
> > > >
> > > > right, I think that needs to be clearified.
> > > >
> > > >> On your point on session, the question
is not whether a portlet can
> > > >> return a new sessionID or not, but
how it relates to the sessionID
> > > >> returned via a getMarkup/pbia/he. If
a producer chooses to return a
> > > >> new sessionID, I would expect the consumer
to use that in
> subsequent
> > > >> calls. This is because, from the consumer's
point, getResource is
> just
> > > >> another request for a portlet.
> > > >>
> > > >> I can see at least one use case for
returning a new sessionID. That
> is
> > > >> when a portlet is generating the resource,
e.g. to generate some
> > > >> response for an Ajax request. It should
be able to create new
> session
> > > >> either when there is no session currently,
or when the current
> session
> > > >> expired.
> > > >>
> > > >
> > > > what happens if you make a parallel render
call in that case?
> Shouldn't
> > > > the spec that in that case that the session
id returned by both
> calls
> > > > must be the same (like in the JSR 168 case
where different portlets
> of
> > > > the same web app can create a new session
in parallel at render
> time)?
> > > >
> > > >> On the question of title, my interpretation
is that the title
> returned
> > > >> via any operation applies to the current
markup returned, and it is
> up
> > > >> to the consumer to treat it as a new
title replacing the current
> one,
> > > >> or use it just for that rendition of
the markup/resource. So, I
> don't
> > > >> an issue.
> > > >>
> > > >
> > > > Still sounds confusing to me that the spec
states for title:
> > > > " The title the Portlet would prefer
to be used in any decoration of
> the
> > > > markup."
> > > > what are decorations for resources?
> > > >
> > > > Stefan
> > > >
> > > >> Subbu
> > > >>
> > > >> Stefan Hepper wrote:
> > > >>> Subbu Allamaraju wrote:
> > > >>>> Stefan Hepper wrote:
> > > >>>>> I've some questions regarding
the resource URLs. From the
> current
> > > >>>>> version of the spec it
is not clear to me how getResource and
> > > >>>>> getMarkup relate to each
other.
> > > >>>>> - What happens if I specific
new nav params, new portlet mode /
> > > >>>>> window state on the resource
URL? Will they be valid for the
> next
> > > >>>>> getMarkup call?
> > > >>>>
> > > >>>> Should they be? I think the
semantics are the same as that of a
> > > >>>> render URL.
> > > >>>
> > > >>> Depends if we say that getResource
and getMarkup are related or
> not.
> > > >>> I think they they should be related
and that there should be only
> one
> > > >>> set of portlet mode, window state,
nav params, per POP. I also
> think
> > > >>> that we should not allow a resource
URL to change this state, that
> > > >>> doesn't make sense to me.
> > > >>>
> > > >>>>
> > > >>>>> - What are the semantics
for portlet mode and window state when
> > > >>>>> rendering a resource? What
portlet mode and window state will
> the
> > > >>>>> portlet receive if nothing
is specified?
> > > >>>>
> > > >>>> I would assume that this is
up to the resource handler or the
> > > >>>> producer or portlet.
> > > >>>>
> > > >>>
> > > >>> You mean that the result may be
different per mode or window
> state? I
> > > >>> can see use cases for this, but
think that the spec should state
> that
> > > >>> the getResource calls gets the
current portlet mode and window
> state.
> > > >>>
> > > >>>>> - Can you specify navigational
state on a resource URL? (yes I
> > > >>>>> assume based on the current
spec)
> > > >>>>
> > > >>>> Yes
> > > >>>>
> > > >>>>> - Why can the getResource
call create a new session?
> > > >>>>
> > > >>>> It might, if the consumer does
not include the current sessionID.
> > > >>>>
> > > >>>
> > > >>> Why would a getResource call need
to create a session? What would
> be
> > > >>> the use case?
> > > >>>
> > > >>>> Could you elaborate on why
you think getResource and getMarkup
> are
> > > >>>> not related. As far as the
context provided by the consumer is
> > > >>>> concerned, they are similar.
The only difference is on the
> semantics
> > > >>>> of the response.
> > > >>>>
> > > >>>
> > > >>> When reading the spec again I could
not find a sentence saying
> that
> > > >>> they are related. I think this
needs to be clarified.
> > > >>>
> > > >>> Another thing I noted is that the
getResource operation is allowed
> to
> > > >>> change the portlet title. I think
that does not really make sense.
> > > >>> What is the use case for allowing
to change the title in
> getResource?
> > > >>>
> > > >>> Stefan
> > > >>>
> > > >>>> Subbu
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> ---------------------------------------------------------------------
> > > >>> 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
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]