[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 thatI 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.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). -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)describinghow a stateless Consumer would need to write any new sessioninformationto 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 havebeenreceived 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 lateknowledgeof 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 markupparams, 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 theintegrityof > > the aggregated page requires that these not be supported onresource> > URLs, unless someone can point out how a Consumer's decorationscouldbe > > 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 aparameter with> a specific window state, the consumer is merely asking theproducer to> generate markup or resource reflecting that window state. I don'tsee 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 URLincludes therequest 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 UIbehavior andthis certainly contradicts it. > > - title: This is another case of the Portlet havingopportunity> > 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 isdoing> with the markup or resource. If the consumer is aggregating theresponse> into a page that has windows-like titlebars, it might use thetitle in> the manner you suggest. Other usages of this field are possible. For > example, a special purpose consumer may be displaying resourcesin 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 newsession, but> > how a stateless Consumer could handle it is important. > > I agree that the stateless consumer use cases break down withsessionID> returned from getMarkup or getResource. As Mike points out, wehave this> problem with getMarkup itself. > > > In summary, perhaps we need to more explicitly state the semantic > > difference between these operations. Do people generally agreewith the> > semantics I have described above? Do people have otherproposals which> > keep the stateless Consumer supported? Are people willing tothrow 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 ofstate 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 thatthe pagestate is opaque/mainted by the consumer. Now you seem to imply that portlets/resources can manipulate theoverallpage 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 theoverallstate. > > 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 parallelrequestsis > > possible, and I don't know if the spec can help either theconsumer or> > the producer. > > > > One way of avoiding returning new sessionIDs is to somehow tie > > initCookie with sessionIDs, and raise InvalidCookie fault whenthere is> > a need to return new sessionID. It is possible to design aproducer 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 statespecified ina > > >> resource URL applies to subsequent getMarkup/pbia/he callsor not.> > >> The spec leaves this open. It also leaves the same questionopenfor > > >> normal action and render URLs. > > >> > > > > > > right, I think that needs to be clearified. > > > > > >> On your point on session, the question is not whether aportlet can> > >> return a new sessionID or not, but how it relates to thesessionID> > >> returned via a getMarkup/pbia/he. If a producer chooses toreturn a> > >> new sessionID, I would expect the consumer to use that in subsequent > > >> calls. This is because, from the consumer's point,getResource isjust > > >> another request for a portlet. > > >> > > >> I can see at least one use case for returning a newsessionID. Thatis > > >> when a portlet is generating the resource, e.g. to generatesome> > >> 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 differentportletsof > > > 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 isup > > >> to the consumer to treat it as a new title replacing thecurrentone, > > >> or use it just for that rendition of the markup/resource. So,Idon't > > >> an issue. > > >> > > > > > > Still sounds confusing to me that the spec states for title: > > > " The title the Portlet would prefer to be used in anydecoration ofthe > > > 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 howgetResource and> > >>>>> getMarkup relate to each other. > > >>>>> - What happens if I specific new nav params, new portletmode /> > >>>>> window state on the resource URL? Will they be valid forthenext > > >>>>> getMarkup call? > > >>>> > > >>>> Should they be? I think the semantics are the same asthat of a> > >>>> render URL. > > >>> > > >>> Depends if we say that getResource and getMarkup arerelated ornot. > > >>> I think they they should be related and that there shouldbe onlyone > > >>> set of portlet mode, window state, nav params, per POP. Ialsothink > > >>> that we should not allow a resource URL to change thisstate, that> > >>> doesn't make sense to me. > > >>> > > >>>> > > >>>>> - What are the semantics for portlet mode and windowstate when> > >>>>> rendering a resource? What portlet mode and window statewillthe > > >>>>> portlet receive if nothing is specified? > > >>>> > > >>>> I would assume that this is up to the resource handler orthe> > >>>> 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 shouldstatethat > > >>> the getResource calls gets the current portlet mode andwindowstate. > > >>> > > >>>>> - 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 currentsessionID.> > >>>> > > >>> > > >>> Why would a getResource call need to create a session?What wouldbe > > >>> the use case? > > >>> > > >>>> Could you elaborate on why you think getResource andgetMarkupare > > >>>> not related. As far as the context provided by theconsumer 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 sentencesayingthat > > >>> they are related. I think this needs to be clarified. > > >>> > > >>> Another thing I noted is that the getResource operation isallowedto > > >>> change the portlet title. I think that does not reallymake 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 theOASIS TCthat > > >>> generates this mail. You may a link to this group and allyourTCs > > >>> 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 OASISTCthat > > >> generates this mail. You may a link to this group and allyour TCsin > > >> OASIS > > >> at: > > >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >> > > >> > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe from this mail list, you must leave the OASISTC that> > > generates this mail. You may a link to this group and allyour TCsin > > > 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 TCthat> > generates this mail. You may a link to this group and all yourTCs inOASIS > > 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 yourTCs 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 yourTCs inOASIS > 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 TCsin OASISat: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php--------------------------------------------------------------------- Tounsubscribe 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]