[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 36 - Proposal to vote - Multiple instances of eventhandler
+1 ----- Original Message ----- From: "Harvey Reed" <hreed@sonicsoftware.com> To: "'Assaf Arkin'" <arkin@intalio.com> Cc: <ygoland@bea.com>; "'Satish Thatte'" <satisht@microsoft.com>; <wsbpel@lists.oasis-open.org> Sent: Thursday, October 02, 2003 1:02 PM Subject: RE: [wsbpel] Issue 36 - Proposal to vote - Multiple instances of event handler > Go for it > ++harvey > > -----Original Message----- > From: Assaf Arkin [mailto:arkin@intalio.com] > Sent: Thursday, October 02, 2003 3:38 PM > To: Harvey Reed > Cc: ygoland@bea.com; 'Satish Thatte'; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue 36 - Proposal to vote - Multiple instances of > event handler > > Harvey Reed wrote: > > >The thematic approach is for the champion to work the issue out in threads > >(like what is happening here), then present a proposal. In this case the > >champion is a small group. Then the motion is to accept or reject. If there > >are alternatives then it's still to early to present a proposal. > > > So if I understand it correctly, we narrowed it down to a list of two > options, Satish presented the pros & cons of either one, so far Satish, > Edwin and myself are the only ones expressing any opinion in favor of > one or the other, which implies that we are the only one interested in > which particular options it ends up being. The group would find it > easier if we just narrow it down and present a single option. Is that > correct? > > In that case I don't see a problem with us presenting a single option > for the group to vote on. > > arkin > > >++Harvey > > > > > >-----Original Message----- > >From: Assaf Arkin [mailto:arkin@intalio.com] > >Sent: Thursday, October 02, 2003 3:22 PM > >To: ygoland@bea.com > >Cc: 'Satish Thatte'; wsbpel@lists.oasis-open.org > >Subject: Re: [wsbpel] Issue 36 - Proposal to vote - Multiple instances of > >event handler > > > >The reason we have two options is to not make two separate issues out of > >it, but fold them into one, while at the same time presenting two > >alternatives. I do agree that having one option would make the voting > >simpler, but I also got the impression that people want to discuss this > >during the conf call. Perhaps we could fold it into one option during > >the conf call if there's no strong feeling either way. > > > >If it does boil down to only Satish, Edwin and myself having any > >opinion, then I guess we could decide now and present only one option > >during the conf call. But does that give the group enough info into the > >alternatives? > > > >The question is, does anyone else have an opinion in favor of a > >particular option, or do people just want one option to vote on? > > > >arkin > > > > > >Yaron Goland wrote: > > > > > > > >>On a procedural note motions are typically 'yes or no' not multiple choice > >>because multiple choices leads to confusion. Could the parties involved > >>possibly come to an internal consensus and just put up a single option to > >> > >> > >be > > > > > >>voted on? > >> > >>My apathy as to which choice to pick is such that I don't have strong > >>feelings either way. But it seems both Edwin and Satish want option 2. So > >>why not just pick that one for the motion? > >> > >> > >> > >> > >> > >>>-----Original Message----- > >>>From: Satish Thatte [mailto:satisht@microsoft.com] > >>>Sent: Tuesday, September 30, 2003 10:42 PM > >>>To: Assaf Arkin; wsbpel@lists.oasis-open.org > >>>Subject: RE: [wsbpel] Issue 36 - Proposal to vote - Multiple instances > >>>of event handler > >>> > >>> > >>>My 2 cents on the options. > >>> > >>>The advantage of Assaf's option 1 is minimality and consistency with > >>>"pick". > >>> > >>>The disadvantage is that we now have a variable declaration where the > >>>type is specified externally. > >>> > >>>Related issue regarding broken catch syntax (issue 68) will raise this > >>>problem again: when the fault name is missing the type must be > >>>specified. > >>> > >>>I prefer the regularity of always declaring the type when you > >>>declare a > >>>variable, whether within <variables> or catch handlers or event > >>>handlers. > >>> > >>>An advantage of option 2 is redundancy that is an aid to static > >>>checking, along the same lines as the createInstance attribute on an > >>>initial receive. > >>> > >>>Satish > >>> > >>>-----Original Message----- > >>>From: Assaf Arkin [mailto:arkin@intalio.com] > >>>Sent: Tuesday, September 30, 2003 7:51 PM > >>>To: wsbpel@lists.oasis-open.org > >>>Subject: [wsbpel] Issue 36 - Proposal to vote - Multiple instances of > >>>event handler > >>> > >>>Proposal to resolve issue 36. > >>> > >>>The semantics of event handler would be changed to allow the variable > >>>used to capture the input message to be treated local to the event > >>>handler instance: > >>> > >>>1. The name of the variable is given in the variable attribute. > >>> > >>>2. The variable type must be the same as the type of the input message > >>>defined by referenced operation. > >>> > >>>3. The event handler declares a variable of that name and type that is > >>>scoped to the event handler activity. > >>> > >>>4. Upon receipt of the input message the event handler > >>>assigns the input > >>>message to the variable before proceeding to perform the event handler > >>>activity. > >>> > >>>5. Since the variable is scoped to that activity, two instances of the > >>>activity (whether executed seriallly or > >>>concurrently) do not operate on the same variable. > >>> > >>>From that base proposal we have to options that we should vote on: > >>> > >>>Option 1: > >>> > >>>1. Retain the element name onMessage > >>> > >>>2. The variable type is derived from the message type used as input by > >>>the referenced operation > >>> > >>>Option 2: > >>> > >>>1. Rename eventHandler/onMessage to eventHandler/onEvent > >>> > >>>2. The attribute messageType specifies the variable type by > >>>referencing > >>>the message type definition using its QName. > >>> > >>>arkin > >>> > >>> > >>> > >>> > >>> > >>> > >>>To unsubscribe from this mailing list (and be removed from > >>>the roster of > >>>the OASIS TC), go to > >>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le > >>> > >>> > >>> > >>> > >>ave_workgr > >>oup.php. > >> > >> > >> > >> > >>To unsubscribe from this mailing list (and be removed from the roster of > >> > >> > >the > > > > > >>OASIS TC), go to > >>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgrou > p > >> > >> > >. > > > > > >>php. > >> > >> > >> > >>------------------------------------------------------------------------ > >> > >>To unsubscribe from this mailing list (and be removed from the roster of > >> > >> > >the OASIS TC), go to > >http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup > . > >php. > > > > > > > > > > > >To unsubscribe from this mailing list (and be removed from the roster of > the > >OASIS TC), go to > >http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup > . > >php. > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]