Events vs StateChanges

[Michael Freedman <Michael.Freedman@oracle.com>]

Last week we discussed the value of defining an in-band event model vs. 
a state changed model.  Here are some further thoughts:
      I see the following types of events that could be dealt with:
       a) WSRP events -- these are well known events that WSRP defines 
-- currently these "events" are implicit in our protocol being 
explicitly represented as lifecycle calls [and their 
parameters/returns]:  i.e. perform action,  render.  Examples of such 
events we might consider adding are Begin/EndTransaction.  I.e. placing 
a series of calls between portlets within a consistent transaction. 
[Important once we start propagating state changes/data across portlets?]
       b) Mappable events -- these are events typically defined by the 
producer [though also can be done by the consumer] that the receiving 
portlet is not aware of.  Consumers provide a facility to declare 
mappings from one portlets event namespace to anothers.  Yossi indicated 
he will provide some examples of this.
       c) Known events -- these are events typically defined by the 
producer [though also can be done by the consumer] that the receiving 
portlet is aware of.  No mapping is necessary, consumer merely route the 
events to interested parties.  Commonly used within a producer to build 
cooperation within a known set or portlets or by producers building 
building-block portlets that it hopes other producers will include in a 
cooperating set.
       d) Mappable state changes -- probably the most common form of 
mappable event where the consumer acts as a mediator for data exchange 
between two portlets.  I.e. an action results in state changes, a 
portion of which a portlet wishes to publish [e.g. bug report number]. 
 The consumer understands that the portlet "publishes" this data and 
supports mapping it to similarly published state in another portlet.
      e) Known state changes -- like known events, the consumer doesn't 
provide any mapping -- the sending/receiving portlets understand/agree 
on the data being exchanged via prior knowledge/agreement.

I agree with Yossi that Mappable events are a generalization of mappable 
state changes.  However, I am not yet convinced that our in-band 
mechansim needs this generalization.  For me there is a developer and 
user cost/complexity to introducing MappableEvents here.  As I don't yet 
have an example of a pure event -- one that indicates no state 
change/has no associated state -- A mappable event leaves the developer 
in the quandry of whether to define a new event for every state change 
or whether to expose the state changes via a common event [e.g. 
UpdateModel].  The later has the benefit of having a single form 
allowing the consumer to present a simplified user interaction -- map 
from this portlets published data to the other ones.  When individually 
named events are involved the user must first choose the event they want 
to map and then map the data between the events.  For me, this is an 
unnecessary complication to the user interaction. Until I see/understand 
the use cases for in-band mappable events that aren't satisfied by 
mappable state changes my preference is to limit our in-band mechanism 
just to mappable state changes.  

As for (c) and (e) -- known events/state changes -- should we care and 
if so what is its priority?  Mappable events/state changes is a superset 
of the known case -- should we care and if so is it a priority to 
support Consumers who merely want to deal with distpaching/managing 
known events/state changes but not mappable ones?  
    -Mike-