[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Clearification: Resource URLs and markup params, etc.
Yep. I wasn't intending to say that the spec indicate that extensions can be used. I was merely a comment to encourage an alternative route for those in the committee who may be interested in pushing the spec in the short term to achieve this function. -Mike- Subbu Allamaraju wrote: > 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]