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:
- 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.
- 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].
- 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].
- 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.
- 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
|