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 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