[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Clearification: Resource URLs and markup params, etc.
ok right, this was a misunderstanding then.
And that's why the return of new sessions in getMarkup is semi-optimal
because it forces the Consumer to buffer all markup fragments first from
all portlets before flushing it out the browser.
Otherwise the session could not be well maintainted between browser and
consumer.
I'm not sure if the servlet spec allows to modify an exisiting HTTP session
even though the response is committed (i.e. headers and status written). I
would assume that it can.
Alternatively this forces Consumers to always maintain a session between
browser and itself in order to being prepared that a portlet might return a
new session in getMarkup().
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:47 PM cc
Subject
Re: [wsrp] Clearification: Resource
URLs and markup params, etc.
I am not sure I understand -- and maybe its because I wasn't clear -- I was
reacting to Rich's statement that
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).
I was commenting that consumers can't store new sessionIds in consumer
cookies [to be stateless] if the response body has already begun --
something likely true in the agreegated [getMarkup] case.
-Mike-
Richard Jacob wrote:
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]