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 agree with Rich's summary.
There is no real good way to modify state / window state /mode by resources
because the aggregated markup is already passed to the browser. Remember:
our WSRP protocol defines the consumer as an aggregator and control point
of the page passed to the browser, including the overall state information.

I tend to agree with Mike on the session question although I'm not an
enthusiast on creating sessions in getMarkup.
Conceptually both could (or even should?) behave the same way.

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/20/06 05:45 PM                                          cc 
                                                                           
                                                                   Subject 
                                       Re: [wsrp] Clearification: Resource 
                                       URLs and markup params, etc.        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Yes, I generally agree with the semantics you have described.  I think it
is premature for us to warp getResource into the solution for getting a
portlet fragment -- i.e. supporting Ajax.  I think it is just as likely, if
not more so, that we will model this via another API and keep getResource
as an in protocol synonym for our proxy resource function.

As for stateless consumer, huh?  getMarkup already returns a SessionContext
pretty much requiring a stateful consumer or at least adding such language
to getResource would seem to add no additional burden.
    -Mike-

Rich Thompson wrote:

      This thread happened during a period when I had connectivity issues
      and I am just catching up on such threads.

      While there are a number of particular questions raised, the larger
      issue appears to be a need for greater clarity on the relationship
      between getMarkup and getResource. I suspect the confusion arises
      because of the similarity in signature due to both possibly
      generating markup while the difference between them is in the
      semantics. Here is my take on this difference:

       - getMarkup: Semantics are that the Consumer is aggregating portlets
      into a page. The signature supplies data to assist in generating
      appropriate markup (e.g. mode, navState, etc) and allows the return
      to impact more than just the Portlet's portion of the aggregated page
      (e.g. title). Render URLs cause getMarkup invocations and are allowed
      to impact most pieces of the supplied data.

      - getResource: Semantics are that the client is requesting additional
      information (image, data, markup, etc) of the Portlet. This tunnels
      through the Consumer as a SOAP request, but otherwise does not impact
      the Consumer's handling of the page. The one processing requirement I
      could see placing on Consumers is retaining any new sessionID the
      Portlet returns, but even that is questionable. The reason it is
      questionable is that we explicitly state that a stateless Consumer is
      one of he design points the protocol supports. Adding a requirement
      to maintain such returned sessionIDs is tantamount to requiring the
      Consumer be stateful. I would want to think through reasonable
      approaches for a stateless Consumer before approving such a
      requirement. Relative to specific:
            - 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.
             - 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
             - 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.

      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?

      Rich

                                                                           
 Subbu Allamaraju                                                          
 <subbu@bea.com>                                                           
                                                                           
                                                                        To 
 02/15/06 11:48 AM                      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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]