[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Clearification: Resource URLs and markup params, etc.
Mike, I agree that we, as a TC, may be getting ahead of ourselves here. But whether to use extensions or some spec-provided approach is an implementation question, and the spec does not need to make a statement preferring one over the other. Subbu Michael Freedman wrote: > You may have mistinterpreted what I meant. We have not yet had a > discussion whether getResource is a "general solution" for Ajax like use > cases. From its current functional standpoint it handles some of these > use cases but not others. I can see us just as easily providing a > "general solution" by introducing a specific mechanism or extending > pbia/getMarkup as extending getResource. Until we have that discussion > I think its inappropriate for us to patch getResource with additional > features desired primarily to support Ajax-like use cases. What's wrong > with encouraging folks to experiment with solutions using extensions > until we can turn our attention to this area? > -Mike- > > Subbu Allamaraju wrote: > >> Michael Freedman wrote: >> >>> 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. >> >> >> If it is the general interpretation that getResource is not a general >> solution for Ajax like use cases, we have bigger limitation of the >> spec at hand. >> >> At a conceptual level, the spec does not and should not attempt to >> define what a resource is. Given that, I don't see why it is premature >> for WSRP 2.0 users to rely on getResource for such use cases. >> >>> 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. >> >> >> Good point. >> >> Subbu >> >>> 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>* >>>> >>>> 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 >>> >>> >> >> _______________________________________________________________________ >> Notice: This email message, together with any attachments, may contain >> information of BEA Systems, Inc., its subsidiaries and affiliated >> entities, that may be confidential, proprietary, copyrighted and/or >> legally privileged, and is intended solely for the use of the individual >> or entity named in this message. If you are not the intended recipient, >> and have received this message in error, please immediately return this >> by email and then delete it. >> >> --------------------------------------------------------------------- >> 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]