[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 event handler
Hi Assaf, My preference would be option #2. Have a good week end! Edwin > -----Original Message----- > From: Assaf Arkin [mailto:arkin@intalio.com] > Sent: Friday, October 03, 2003 4:18 PM > To: Francisco Curbera > Cc: Harvey Reed; 'Satish Thatte'; > wsbpel@lists.oasis-open.org; ygoland@bea.com > Subject: Re: [wsbpel] Issue 36 - Proposal to vote - Multiple > instances of event handler > > Satish and Edwin, > > Are you both in favor of option 2? > > arkin > > Francisco Curbera wrote: > > > > > > >If you guys are deciding what option to present to the group for > >voting, I would really appreciate if you selected option 2 ;-). > > > >Paco > > > > > > > > > > > Assaf Arkin > > > <arkin@intalio.co To: > Harvey Reed <hreed@sonicsoftware.com> > > > m> cc: > ygoland@bea.com, "'Satish Thatte'" <satisht@microsoft.com>, > > > > wsbpel@lists.oasis-open.org > > > 10/02/2003 03:38 Subject: Re: > [wsbpel] Issue 36 - Proposal to vote - Multiple instances of event > > PM 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_wor > >>>kgroup > >>> > >>> > > > > > > > >>> > >>> > >>. > >> > >> > >> > >> > >>>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/l eave_workg > >roup.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/le ave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]