[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] redirectURL allowed in handleEvents response?
The use of the term "optional" here is used to indicate that this
phase/step only occurs if its a necessary precursor to getting the
markup. I.e. there are many situations in which the consumer needs to
get the markup from the producer where the consumer has neither
directly interacted with that portlet nor sent it an event. In such
circumstances only the getmarkup step is called. When a user interacts
directly with the portlet the PBI is called as the first step and then
if events are raised and their distribution supported by the consumer
[and they aer mapped to something by the consumer] those HEs are called
before we finish up with the getmarkup call. Rich you might consider dropping the "(optional)" on each of the first two steps and merely explain the variation to avoid this type of confusion. -Mike- sleland@notesdev.ibm.com wrote: The wsrp-specification-2.0-draft-11.doc, section 3.12, to me reads like the consumer has the right to decide whether or not to invoke both PBI and HandleEvents, and is required to invoke getMarkup. That's no longer correct? -sl Michael Freedman <michael.freedman @oracle.com> To sleland@notesdev.ibm.com 08/18/2005 01:54 cc PM wsrp@lists.oasis-open.org Subject Re: [wsrp] redirectURL allowed in handleEvents response? PBI isn't optional from either the producer or the consumer perspective. Supporting events is optional from the consumer perspective. The producer must provide a signature for HandleEvents but can ignore any submissions. On your second point given technology we can't say its true that a HandleEvents would never need/want to do a redirect. My points however say that given the current limited semantics of redirect that in a loosely coupled coordination environment such a redirect has ambiguous meaning which if we leave open ended for the consumer to disambiguate leads to a situation where the consumer can operate the producer in an indeterminate state -- which I further go on to say is bad/wrong. In the tightly couple coordination environment where I believe its less ambiguous/more useful to redirect, I point out that the constituents of the coordination can rely on their tight coupling [i.e. they can use the event system itself] to send such redirects. -Mike- sleland@notesdev.ibm.com wrote:If both PerformBlockingInteraction and HandleEvents are optional steps in the protocol, and you restrict the ability for a producer to respond witharedirect to only PBI, aren't you then requiring consumers that are willing to handle redirects to call PBI? Also, since PBI is specified to occur prior to HandleEvents, allowing only PBI to issue redirects implies that nothing which occurs in HandleEvents could cause a producer to want to issue a redirect. Is that true? Regards, -slMichael Freedman<michael.freedman@oracle.com> Towsrp@lists.oasis-open.org08/17/2005 07:59 ccPMSubjectRe: [wsrp] redirectURL allowed inhandleEvents response?Subbu's primary argument seems to boil down to recognizing thesimilaritiesbetween interactions as represented by PerformBlockingInteraction andeventprocessing [HandleEvents]. He has observed that the only distinguishing feature between the responses of the PBI and HE is that HE doesn't allow you to return a redirect. He doesn't see reasons for this discrepency and though providing no specific use cases worries that by not correcting itwewill later regret this decision as when real world needs are thwarted. I however do see reasons in 2.0 to distinguish between these two calls and further believe that even when we leave the specification as it is, that all potential redirect usages are already expressible in thespecification.Here is my point of view: Reasons for not adding redirect to HandleEvents/reasons PBI is different then HE: 1. Incorrectness (1): My primary reason for leaving redirects out of HandleEvents is that unlike PBI, its semantics rely on consumer policy/choice which leads to incorrectness. Because PBI is a synchronous operation we have very tight redirect semantics from the perspective of the producer. A redirect replaces the normal interaction response and directs the consumer to flow to an external resource [not WSRP managed] onbehalfof all consumer entities scoped to this request. In the simple case [Portal] this means the producer tells the consumer to redirect [the client] to an URL/site that is not relative to the consumer. The key in the situation above is that returning a redirect is mutually exclusive from returning an [Interaction] UpdateResponse. Because of the mutual exclusion the producer has a right to expect the redirect will occur as otherwise it is running in an indeterminate state, as its unable to reflect updated state in its response. This leads us to clear and simple requirements for the consumer: honor the redirect or consider it an error condition. HandleEvents however isn't a synchronous operation. This means that unless the producer is running in a controlled environment in which both the consumer and producer are designed to operate there aremanypossible situations for which we must provide well defined semantics if the producer is going to ensure it doesn't get into an indeterminate state without it being considered an error condition. Unfortunately Subbu's/the current proposal doesn't address this choosing instead to leave the barn door open saying redirect support from a HandleEvent is entirely a consumer policy decision including such policies as not supporting the redirect in any/all situations when returned from HandleEvent. This leaves the door wide open for the consumer to operate the producer normally when its in an indeterminate state. This is incorrect from a specification pointofview. I.e. correct -- both sides reflect that a possibility of leaving the portlet in an indeterminate state is an error condition; incorrect -- the consumer is allowed/encouraged to operate the portlet normally when it is in an indeterminate state. 2. Not Interoperable: For purposes of this point, I define interoperablity to mean that from the end users perspective the portlet behaves in a similar manner when run in different consumers. Clearly this is not thecasegiven we want to leave the handling of redirects from a HandleEvents call as a consumer policy decision*. One might ask however why this is distinguished from the generic interoperable question that allows consumers the option to support events in the first place? The difference is that redirects always define an operation that impacts the users view of that portletwhileevents [generally] do not. Yes, other portlets in context are impacted if portlet raising the event runs in a consumer thatchoosesnot to distribute it but this portlet is not [Note: this argument when extended further says that a event chain greater then 1 cycleisalso often not interoperable]. 3. Supports bad UI Remember, that unless the portlet is running in a controlled environment in which the consumer and other interested portletsagreeon supporting a specific form of coordination via events, theportlethas no notion of how the event it raises will be used and even who might receive it. In such a loosley coupled environment won't many end users be surprised when performing an action in a portletresultsin them being redirected to some foreign location when instructed so by another portlet on the page that has happened to handle an event raised by this portlet from its action? This in part has led us to see the need for allowing consumer policy to direct the handling of such redirects -- so that they can controll/enforce their notion of what good UI is based on how loosely or tightly coupled the coordination is [as only they know]. 4. Our future interest in expanding/redefining redirect semantics is hampered by adding it to HandleEvents. Redirect is currently a very limited function. It is mutally exclusive from a regular response hence prevents consumers applying policies without having to put the portlet into an indeterminate state. It only allows you to express a redirect to a non-consumer managed resource. This greater limits an ability to transfer state between the redirecter and redirectee. Each of these are strong/valid reasons for us to redefine/extend redirect support [in the future]. It will be much easier to do this [and give us themostflexibility] if only the current limited/tight semantics of PBI are expressed in 2.0. 5. Cooperating portlets/consumers can model redirect behavior in HandleEvents without us adding it to the response. Many of the above arguments have focused on a loosely coupled system where a portlet has no expectations on either the consumer environment it is running and/or the outcome that occurs when it raises an event. There are however many more tightly coupled coordination situations where a set of portlets are designed to work together in a specific way and a consumer is instructed on how it is expected to behave/configure the portlets so the desired result is delivered. In such an environment its reasonable to suggest that a redirect is one valid outcome of event processing. However because of this tight coupling I contend its very reasonable to express the redirect via an event itself vs. directly in the protocol as thisnotonly effectively works for the above situation but also easilyallowsthe raising portlet to handle the case the coordination is not properly set up/supported and the redirect doesn't happen. I.e. it can return information that leaves it in a determinate state if the redirect doesn't occur. -Mike- Subbu Allamaraju wrote: Thanks Rich, for reminding. Here is my summary. The key point is to keep symmetry in the specification between interactions and event processing. As the designers of a specification (and not an implementation) we ought to allow such a symmetry so that the spec says closer to HTTP. I can agree with Mike and Richard (per his mail today) that typical portal consumers may find it difficult to honor redirects in event processing. But in WSRP, portals make up just one class ofconsumers,and the spec need not favor one kind over another. Regards, Subbu Rich Thompson wrote: This issue has failed to develop a consensus within the Interfaces SC. In preparation for holding a vote during the August 25th TC call, this is an email thread for Subbu and Mike to summarize the opposing points of view. Rather than rehash the full discussion, I would ask that questions be restricted to any points about those summaries which need clarification. Subbu, would you post a summary in favor of adding this capability first so that we have a chance of capturing this in a single email thread?---------------------------------------------------------------------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 thatgeneratesthis 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]