[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Clearification: Resource URLs and markup params, etc.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]