OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-coord message

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

Subject: Re: [wsrp-coord] Events vs StateChanges

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
        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.


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

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