[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Clearification: Resource URLs and markup params, etc.
but the getResource request is triggered by a new HTTP request to the
Consumer.
Therefor the HTTP response, the equivalent of the getResource response,
could set a new cookie.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Michael Freedman
<michael.freedman
@oracle.com> To
WSRP TC <wsrp@lists.oasis-open.org>
02/21/06 06:09 PM cc
Subject
Re: [wsrp] Clearification: Resource
URLs and markup params, etc.
I think HTTP disallows writing headers once the body of the message has
started to be sent. Since cookies are sent in headers, I don't think
your suggestion works. Reality is that consumers can be as stateless as
their producers are. Note: producer cookies cause a similar problem as
they can be returned in any markup port request.
-Mike-
Rich Thompson wrote:
>
> 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
>
>
> ---------------------------------------------------------------------
> 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]