[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 with a
>redirect 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,
>-sl
>
>
>
> Michael Freedman
> <michael.freedman
> @oracle.com> To
> wsrp@lists.oasis-open.org
> 08/17/2005 07:59 cc
> PM
> Subject
> Re: [wsrp] redirectURL allowed in
> handleEvents response?
>
>
>
>
>
>
>
>
>
>
>Subbu's primary argument seems to boil down to recognizing the similarities
>between interactions as represented by PerformBlockingInteraction and event
>processing [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 it we
>will 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 the specification.
>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] on behalf
> of 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 are many
> possible 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 point of
> view. 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 the case
> given 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 portlet while
> events [generally] do not. Yes, other portlets in context are
> impacted if portlet raising the event runs in a consumer that chooses
> not to distribute it but this portlet is not [Note: this argument
> when extended further says that a event chain greater then 1 cycle is
> also 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 portlets agree
> on supporting a specific form of coordination via events, the portlet
> has 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 portlet results
> in 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 the most
> flexibility] 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 this not
> only effectively works for the above situation but also easily allows
> the 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 of consumers,
> 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 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]