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.
Regards,
Andre
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.
Questions:
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.
Rich
Andre Kramer
<andre.kramer@eu.citrix.com>
12/14/2004 03:57 AM
|
To
|
"'Richard Jacob'"
<richard.jacob@de.ibm.com>, Andre Kramer
<andre.kramer@eu.citrix.com>
|
cc
|
wsrp@lists.oasis-open.org
|
Subject
|
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.
Regards,
Andre
-----Original
Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
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
Email: mailto:richard.jacob@de.ibm.com
Andre Kramer
<andre.kramer@eu.
citrix.com>
To
wsrp@lists.oasis-open.org
12/13/2004 03:17
cc
PM
Subject
RE: [wsrp] handleEvent
or
handleEvents?
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.
Regards,
Andre
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
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>
To
12/10/2004 07:06 AM
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