But the consumer is not required to dispatch all or certain events. So,
any assumptions on ordering would break.
Subbu
Spector, Artem wrote:
> But if we say that event distribution is blocking (we almost agreed on
> it, didn’t we? J), then the event order will be well-defined and will
> not depend on network etc.
>
>
>
> Artem
>
>
>
> ------------------------------------------------------------------------
>
> *From:* Rich Thompson [mailto:]
> *Sent:* Wednesday, March 09, 2005 3:41 PM
> *To:*
> *Subject:* RE: [wsrp] spec-2.0-draft-05: events and blocking actions
>
>
>
>
> I would note that multiple portlets couldn't depend on events between
> them being ordered even outside the Consumer's option to reorder the
> events it delivers due to network and varying workload effects on the
> different Producers.
>
> Rich
>
> *"Yossi Tamari" <>*
>
> 03/09/05 04:05 AM
>
>
>
> To
>
>
>
> "Stefan Hepper" <>
>
> cc
>
>
>
> <>
>
> Subject
>
>
>
> RE: [wsrp] spec-2.0-draft-05: events and blocking actions
>
>
>
>
>
>
>
>
>
>
>
>
> I think the reason we required the portlet to return the events in order
> was to allow a consumer that wanted to distribute the events in order,
> to do so.
> I do think this is a meaningful capability, and I don't really think it
> makes the portlet logic more difficult (remember that the portlet gets
> to decide what is the correct order), it just tell implementations "use
> a vector and not a set".
> I do think there should be at least guidance in the spec, for consumers,
> that if they do not have a reason to change the order of the events,
> they should attempt to keep it. It seems to me that developing a
> multiple portlet/multiple events application without being able to
> assume event ordering will be nearly impossible. (In reality my guess
> would be that every event would contain in its internal data some sort
> of timestamp, so that the receiving portlet will be able to manage
> dropping older events).
>
> Yossi.
>
> -----Original Message-----
> From: Stefan Hepper [mailto:]
> Sent: Wednesday, March 09, 2005 9:30 AM
> To: Yossi Tamari
> Cc:
> Subject: Re: [wsrp] spec-2.0-draft-05: events and blocking actions
>
> When reading the spec draft I also was wondering why the event
> processing order is not defined. The event processing oder may influence
>
> the outcome of the eventing. I don't understand why the event array
> needs to be ordered when the event execution on the consumer is
> unspecified. What was the reason for requiring the events be in sequence
>
> in the event array?
>
> For example is it possible to have the following sequence:
>
> P1 returns events e1, e2
> e1 is distributed to P2
> P2 returns events e3, e4
> e3 is distributed to P1
> e4 is distributed to P3
> e2 is distributed to P3
>
> P3 now gets an older event as the last event even as e4 may be the more
> accurate data. I understand that events are not guaranteed to be
> delivered, so P3 may never have gotten e4. However, I think it makes the
>
> portlet logic a bit more complex and it should be stated explicitly in
> the spec that no order is guaranteed.
>
> Stefan
>
>
> Yossi Tamari wrote:
>> 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:
>>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
