OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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
>  




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]