OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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.


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]