wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] handleEvent or handleEvents?
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Mon, 13 Dec 2004 09:10:25 -0500
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 Consumer.
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?
Rich
Andre Kramer <andre.kramer@eu.citrix.com>
12/10/2004 07:06 AM
|
To
| wsrp@lists.oasis-open.org
|
cc
|
|
Subject
| [wsrp] handleEvent or handleEvents? |
|
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?
Regards,
Andre
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]