Two comment bellow, marked with
<YT>.
Yossi.
From: Rich Thompson
[mailto:]
Sent: Tuesday, March 08, 2005 8:49
PM
To:
Subject: RE: [wsrp]
spec-2.0-draft-05: events and blocking actions
Comments in-line
Rich
"Spector, Artem"
<>
03/08/05 12:59 PM
To
<>
cc
Subject
RE: [wsrp] spec-2.0-draft-05: events and
blocking actions
Some
more thoughts about event handling:
1.
Separate between event generations. If a Consumer during
distribution of some events (current generation)
gets a response with a
new portion of events (new generation), it must
finish distribution of
the current generation events before starting
distribution of the next
generation events.
<rdt>Why would this Consumer implementation choice be any
more valid than a choice to queue pending events for each portlet and send them
whenever a portlet is not actively processing events? In particular, why should
the messaging protocol (WSRP) select what is a valid implementation choice for
either of its endpoints (as opposed to defining the semantics of the message
flow)? In the case of handleEvents, the semantics are the Consumer passing a
set of events it chose to distribute to the Portlet. I think how the Consumer
made the choice to distribute these particular events or chose to order the
events should remain a Consumer choice.</rdt>
<YT>I
think leaving the order to be the consumer is under-specifying. Let’s say
that during the portlet’s run, it generated two events “Lakers”
and “Pistons”. We require the portlet to return them in the correct
order (in section 6.4.2.1), but we don’t specify that the consumer need
to send these events to another portlet in the correct order, which means
whether it will display Lakers or Pistons is completely random.
I think
the order SHOULD be kept by the consumer, or at least we need to make such a
recommendation. Of course, we are not even requiring the consumer to propagate the
events, so there is no place for a MUST here. This does not necessarily imply
the concept of generations, which is a simplification of the ordering
requirement.</YT>
2.
What to do when handleEvent() returns redirectUrl? Should the
Consumer redirect immediately, or should it finish
the event
distribution first? What if different Portlets
handling the same event
return different redirectUrls?
Or may be the Consumer should ignore the
redirectUrls of the event
handling, and respect only the result of the
blocking action which has
triggered the event chain?
<rdt> Consensus from previous discussions have been to leave
this up to Consumer policy. Spec should probably explicitly state
this.</rdt>
3.
The optimization when a Portlet sends markup in the
UpdateResponse seems a bit problematic, because
the same Portlet may be
invoked several times within the same
"three-step" loop generating each
time a different markup...
<rdt>Remember that each time a Portlet returns markup, it is
saying this markup reflects its current state. Unless the Portlet changes its
navState, mode or ..., the previously returned markup may be fetched from a
cache.</rdt>
Considering all these complications I would
propose to redesign the
HandleEventResponse so that it will include
neither redirectUrl, nor
Events. This would make the event handling flow
more simple and
consistent.
As for the "cascading multi-generation
events" (which will not be
supported in this case), they have so many side
effects that could
easily cause unpredictable behavior.
<rdt>But they are also essential for a number of use cases.
The only problems I have seen to-date with multiple generations is when people
try to make this loosely-coupled model exhibit tightly-coupled
behavior.</rdt>
<YT>I agree, but like some of
the other questions raised recently around these topics, these are things that
took us some serious discussions to realize. I think we need to add more wordage
to the spec to explain the reasoning behind the decisions, and the expected use
patterns. Otherwise we are going to get the same questions from everybody who
reads the spec and was not part of the discussions…</YT>
Regards,
Artem
-----Original Message-----
From: Subbu Allamaraju [mailto:]
Sent: Monday, March 07, 2005 7:29 PM
To:
Subject: Re: [wsrp] spec-2.0-draft-05: events and
blocking actions
Some more comments below.
Subbu
> From the Producer point of view, handling
the user interactions and
the
> events are very similar tasks. The spec
describes an interaction as an
> "encodable event" (6.4.2), which
points out that interactions and
events
> are just two different ways to invoke the
same Portlet logic.
> This idea however is not expressed strongly
in the spec, which causes
> some confusion. Below is a list of questions:
>
> 1.
HandleEventResponse and BlockingInteractionResponse are
> identical, but defined as two distinct types,
why is this?
>
> <rdt>Opened issue #43</rdt>
I thought we discussed this during last F2F, but I
don't recollect what
the resolution was.
> 2. According to
paragraph 6.4.2.1 Event Handling, the Consumer
> may invoke handleEvent() on different
Portlets simultaneously. But if
> the event handling has the same Producer-side
semantics as processing
> user interaction, all the restrictions
described in paragraph 6.4.1
must
> be applicable as well. Which means that all
the operations on the page
> must be blocked until handleEvent() either
returns or fails.
>
> <rdt>My understanding from the
discussion to-date is that handleEvent
> invocations may happen in parallel, but that
other processing is
blocked
> until the Consumer decides it has no more
events for a particular
> portlet. The Consumer may then start a
getMarkup on that portlet. I'm
> sure we need to be more explicit about this
... do people think that
the
> Consumer must wait for all portlets to exit
the event distribution
step
> before starting to collect markup?
</rdt>
I agree that we need to be explicit. Semantically,
it would be
consistent to specify that event distribution is
blocking.
> 3. What if
HandleEventResponse contains events? Must they be
> processed by the Consumer?
> Let's consider a Consumer processing a page
which contains two
portlets:
> P1 and P2.
> a. Consumer calls
P1.performBlockingInteraction(), and gets
event E1
> b. Consumer
propagates the event to the Portlets:
>
i.
> Question: should the consumer invoke
P1.handleEvent(E1)? I guess
no...
> <rdt>The Consumer is not bound to send
the event to any portlets and I
> expect most will explicitly exclude the
source portlet. Should we make
> this explicit in the spec so that portlets
design for it?</rdt>
It is perfectly valid for P1 to subcribe for E1. I
don't see any reason
to exclude this possibility.
ii.
> Consumer calls P2.handleEvent(E1) and
gets another event E2 in the
> response.
>
iii.
> Must the Consumer call
P1.handleEvent(E2)? If yes, there could be an
> endless loop; if no, the HandleEventResponse
should not contain
events...
> <rdt>The Consumer is free to exit the
event distribution step whenever
> it wants to. As part of loop prevention,
Consumers should have a limit
> on the number of generations of events they
distribute ...</rdt>
>
> Regards,
> Artem
> *Artem Spector* | Portal Platform
Infrastructure | NetWeaver
Application
> Platform | SAP Labs Israel| (+972-9) 7779567
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
