Re: [wsrp-coord] Events vs StateChanges

[Rich Thompson <richt2@us.ibm.com>]

I have now captured this question in
the QuestionSet.doc that I had started. We can consider it after we work
through the general coordination model.

Rich Thompson

Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM> Sent by: Alejandro.Abdelnur@Sun.COM 08/06/2003 01:39 AM

To:        wsrp-coord@lists.oasis-open.org         cc:                 Subject:        Re: [wsrp-coord] Events vs StateChanges

A very comprehensive list of cases to consider. I
would just add to the  
list of things to consider if portlet-mode and window-state changes  
should fall in the category of events. At some point this was discussed
 
(don't remember if JSR168 EG or WSRP TC) but it was tabled for v1.0.

Alejandro

On Tuesday, August 5, 2003, at 04:57  PM, Michael Freedman wrote:

> 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-
>
>
> You may leave a Technical Committee at any time by visiting  
> http://www.oasis-open.org/apps/org/workgroup/wsrp-coord/members/ 
> leave_workgroup.php
>


You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-coord/members/leave_workgroup.php