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] handleEvent or handleEvents?


Very hard to answer in general but think of a "cut and paste" interaction between two portlets:


Use Case: After "highlighting" in first portlet (highlight event generated with highlighted data distributed) and user attempted paste into second -

Second portlet sends "cut&paste" event.


C1 has no "highlightable" portlet. Cut&paste fails to cause anything. Cut&paste fails to cause anything.


C2 has a portlet that can "highlight" but it is not (now) in the highlighted state. User's expectations not met.


C3 has a highlighted portlet but it fails to process the cut part of the cut&paste. The second portlet may wish to inform the user that her cut&paste failed.


C4 has a highlighted portlet but it fails to process the cut part of the cut&paste. A spurious copy for the user to deal with?


Just taking the viewpoint that user feedback is generally good makes C3 seem more intelligent that 1,2 or 4 or than any C that drops events without failure notifications.






From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 14 December 2004 17:55
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] handleEvent or handleEvents?


I'm not sure what this would mean to a portlet. Consider the following variations:

Four different Consumers (C1, C2, C3 & C4) all place a portlet (P1) that generates an event on a page. When the event is generated, the following scenarios happen:

1. On C1's page there is no match to a consuming portlet and the event is thrown away
2. On C2's page there is a matching portlet, but it chooses to throw the event away anyway
3. On C3's page there is a matching portlet to whom the event is distributed, but it fails to process it
4. On C4's page there is a matching portlet to whom the event is distributed and it does not inform the Consumer of any failures when processing the event.

All four Consumers then request P1's markup.

1. What are the use cases for P1 generating different markup for the four different Consumers?
2. What are the use cases for P1 caring that the Consumer received, let alone distributed, the event?
3. While P1 could indicate it is interested in event distribution/processing failures, since each Consumer gets to decide each time whether or not to provide such information to it, what use would a portlet make of the information?

I suspect we are driving toward some core questions of whether the portlet or the Consumer is in charge relative to event distribution.


Andre Kramer <andre.kramer@eu.citrix.com>

12/14/2004 03:57 AM


"'Richard Jacob'" <richard.jacob@de.ibm.com>, Andre Kramer <andre.kramer@eu.citrix.com>




RE: [wsrp] handleEvent or handleEvents?




I agree that we can't postulate reliable event or failure notification. However, best effort delivery of network and event handling failure indications to interested portlets is still useful as it allows them to offer alternative user interactions.


-----Original Message-----
From: Richard Jacob [
Sent: 13 December 2004 18:38

To: Andre Kramer

Cc: wsrp@lists.oasis-open.org

Subject: RE: [wsrp] handleEvent or handleEvents?

One other important point to me is that we really should understand the
nature of events.

Portlets shouldn't rely on event delivery and thus also shouldn't rely on

correct event processing.

We also do not deliver failure events back to the portlet issuing the

original event (this was the first design we had).

Therefore we might want to ask ourselves what event failures are really for

and who will be doing what with this information.

Key point for me is that we shouldn't try to implement a (relyable)

messaging system based on events, i.e. we shouldn't add any

atomicy,rollback, etc. rules to eventing.

Mit freundlichen Gruessen / best regards,

        Richard Jacob

IBM Lab Boeblingen, Germany

Dept.8288, WebSphere Portal Server Development

WSRP Standardization Technical Lead

Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888


            Andre Kramer                                                  
            citrix.com>                                                To
            12/13/2004 03:17                                           cc
                                      RE: [wsrp] handleEvent or          


Recognizing that event processing occurs in rounds would also help the
presentation. Each round involves a consumer delivering a batch of events

to the producer and optionally receiving back a further batch of events

(and failure events) to process.


From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 13 December 2004 14:10

To: wsrp@lists.oasis-open.org

Subject: Re: [wsrp] handleEvent or handleEvents?

The F2F decision was to drop to handleEvent for now due to the issues
involved in handling faults in the batched case. We should work on these

and seek to restore the nature to a batch operation for the reasons you

list. Basically the solution should respect the current overall design:

1. Portlets are loosely coupled components integrated onto the page by the

2. Events are notifications that something has occurred which other

components may use to impact their own state.

3. There are times when a Consumer will care what failures have occurred

(e.g. for retry purposes)

I think if we agree to these guidelines, then relatively simple solutions
to the failure issues in the batch operation can be designed. Any comments

on these as guidelines before we try and design/debate a solution?



Andre Kramer                                                              
12/10/2004 07:06 AM                                 wsrp@lists.oasis-open
                                                    [wsrp] handleEvent or

My comment is on the current 2.0 draft, so I am sending it to the TC list,
even though it is specific to coordination. As initially written,

handleEvent is constrained to only deliver a single (IN) event and requires

the consumer to not deliver a second event while the first is being

processed (but multiple events can be returned by a portlet). This seems an

unworkable solution to me because of (1) network latency and (2) event

processing logically occurs in rounds. Should we start with handleEvents

rather than try to discuss a handleEvent?



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