Re: [RESULT] [VOTE] Pass-by-value related SPI change
OK. I use org.apache.tuscany.sca.invocation.DataExchangeSemantics for now. The changes are checked in under r634778. Thanks, Raymond -- From: "ant elder" <[EMAIL PROTECTED]> Sent: Friday, March 07, 2008 12:20 AM To: Subject: Re: [RESULT] [VOTE] Pass-by-value related SPI change On Wed, Mar 5, 2008 at 6:25 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: Ant (I assume you are leaning to 2 with some name changes) DataExchangeSemantics sounds good for me. Less sure we really need the .feature. in the package name right now if the SPIs are going to reviewed/tidied in the not to distant future but i don't mind so much either way. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Pass-by-value related SPI change
On Wed, Mar 5, 2008 at 6:25 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: Ant (I assume you are leaning to 2 with some name changes) > DataExchangeSemantics sounds good for me. Less sure we really need the .feature. in the package name right now if the SPIs are going to reviewed/tidied in the not to distant future but i don't mind so much either way. ...ant
[RESULT] [VOTE] Pass-by-value related SPI change
The vote is now finished after more than 72 hours. Here is the result: Raymond 1, 2 Sebastien 1,2 Simon Nash 3,2 Venkat 2,1 Simon Laws 2,3 Ant (I assume you are leaning to 2 with some name changes) The result: Option 2 is winning for now. For naming, I propose that use the following: (The feature package will contain optional features that can be implemented) org.apache.tuscany.sca.invocation.feature.DataExchangeSemantics The term DataExchangeSemantics is copied from the SCA assembly spec. Thanks, Raymond -- From: "Simon Laws" <[EMAIL PROTECTED]> Sent: Monday, March 03, 2008 8:51 AM To: ; <[EMAIL PROTECTED]> Subject: Re: [VOTE] Pass-by-value related SPI change On Mon, Mar 3, 2008 at 1:34 PM, ant elder <[EMAIL PROTECTED]> wrote: On Fri, Feb 29, 2008 at 11:44 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > Please vote on one of the following five options to define > allowsPassByReference property for Invokers. You can vote with multiple > choices ordered by your preference. > > [1] Add "boolean allowsPassByReference()" to the Invoker interface > directly > > [2] Add "boolean allowsPassByReference()" to an optional SPI (either a > separate interface or a sub-interface of Invoker) > > [3] Define an "InvokerProperties" interface to encapsulate known > properties > including "allowsPassByReference", change the Provider.createInvoker() to > take InvokerProperties. Add "getInvokerProperties()" to the Invoker > interface. > > [4] Define an "InvokerProperties" class to encapsulate known properties > including "allowsPassByReference", add "getInvokerProperties()" to the > Invoker interface. > > [5] Define an "InvokerProperties" interface to encapsulate known > properties > including "allowsPassByReference", define an "InvocationPropertiesFactory" > interface to create "InvokerProperties", add "getInvokerProperties()" > to > the > Invoker interface. > > My vote is [1], [2]. > > Thanks, > Raymond > > Not breaking existing extensions is the most important to me so I'm less keen on [1]. The current state of the code is [2] which I originally found confusing as the method and interface names didn't seem to match - PassByValueAware/allowsPassByReference - so i might have preferred something like PassByReferenceAware/allowsPassByReference but there has been so much discussion around it i guess i know what its all about now. We do seem to regularly need to add properties like this so i can understand the motivation for the InvokerProperties solutions and I'd be fine with doing that if thats what everyone wants. I know this isn't an explicit vote, but there already isn't consensus on one option so i hope it will be clearer and easier to find consensus by stating my preferences like this. ...ant [2] now [3] later. I like [3] but would like to see us review our SPI more holistically rather than just applying this pattern in one place. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Pass-by-value related SPI change
On Mon, Mar 3, 2008 at 1:34 PM, ant elder <[EMAIL PROTECTED]> wrote: > On Fri, Feb 29, 2008 at 11:44 PM, Raymond Feng <[EMAIL PROTECTED]> > wrote: > > > Hi, > > > > Please vote on one of the following five options to define > > allowsPassByReference property for Invokers. You can vote with multiple > > choices ordered by your preference. > > > > [1] Add "boolean allowsPassByReference()" to the Invoker interface > > directly > > > > [2] Add "boolean allowsPassByReference()" to an optional SPI (either a > > separate interface or a sub-interface of Invoker) > > > > [3] Define an "InvokerProperties" interface to encapsulate known > > properties > > including "allowsPassByReference", change the Provider.createInvoker() > to > > take InvokerProperties. Add "getInvokerProperties()" to the Invoker > > interface. > > > > [4] Define an "InvokerProperties" class to encapsulate known properties > > including "allowsPassByReference", add "getInvokerProperties()" to the > > Invoker interface. > > > > [5] Define an "InvokerProperties" interface to encapsulate known > > properties > > including "allowsPassByReference", define an > "InvocationPropertiesFactory" > > interface to create "InvokerProperties", add "getInvokerProperties()" to > > the > > Invoker interface. > > > > My vote is [1], [2]. > > > > Thanks, > > Raymond > > > > > Not breaking existing extensions is the most important to me so I'm less > keen on [1]. The current state of the code is [2] which I originally found > confusing as the method and interface names didn't seem to match - > PassByValueAware/allowsPassByReference - so i might have preferred > something > like PassByReferenceAware/allowsPassByReference but there has been so > much > discussion around it i guess i know what its all about now. We do seem to > regularly need to add properties like this so i can understand the > motivation for the InvokerProperties solutions and I'd be fine with doing > that if thats what everyone wants. > > I know this isn't an explicit vote, but there already isn't consensus on > one > option so i hope it will be clearer and easier to find consensus by > stating > my preferences like this. > > ...ant > [2] now [3] later. I like [3] but would like to see us review our SPI more holistically rather than just applying this pattern in one place. Simon
Re: [VOTE] Pass-by-value related SPI change
On Fri, Feb 29, 2008 at 11:44 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > Please vote on one of the following five options to define > allowsPassByReference property for Invokers. You can vote with multiple > choices ordered by your preference. > > [1] Add "boolean allowsPassByReference()" to the Invoker interface > directly > > [2] Add "boolean allowsPassByReference()" to an optional SPI (either a > separate interface or a sub-interface of Invoker) > > [3] Define an "InvokerProperties" interface to encapsulate known > properties > including "allowsPassByReference", change the Provider.createInvoker() to > take InvokerProperties. Add "getInvokerProperties()" to the Invoker > interface. > > [4] Define an "InvokerProperties" class to encapsulate known properties > including "allowsPassByReference", add "getInvokerProperties()" to the > Invoker interface. > > [5] Define an "InvokerProperties" interface to encapsulate known > properties > including "allowsPassByReference", define an "InvocationPropertiesFactory" > interface to create "InvokerProperties", add "getInvokerProperties()" to > the > Invoker interface. > > My vote is [1], [2]. > > Thanks, > Raymond > > Not breaking existing extensions is the most important to me so I'm less keen on [1]. The current state of the code is [2] which I originally found confusing as the method and interface names didn't seem to match - PassByValueAware/allowsPassByReference - so i might have preferred something like PassByReferenceAware/allowsPassByReference but there has been so much discussion around it i guess i know what its all about now. We do seem to regularly need to add properties like this so i can understand the motivation for the InvokerProperties solutions and I'd be fine with doing that if thats what everyone wants. I know this isn't an explicit vote, but there already isn't consensus on one option so i hope it will be clearer and easier to find consensus by stating my preferences like this. ...ant
Re: [VOTE] Pass-by-value related SPI change
Raymond Feng wrote: Isn't option [3] on the vote the same as your [n]? [3] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", change the Provider.createInvoker() to take InvokerProperties. Add "getInvokerProperties()" to the Invoker interface. [n] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", add an "InvokerProperties" parameter to the createInvoker() method, and add "getInvokerProperties()" to the Invoker interface. My apologies. I overlooked this one (not sure how, but it could be related to its position in the middle of the list). Yes, this option is the same as my proposal. My vote is [3], [2]. Simon Thanks, Raymond -- From: "Simon Nash" <[EMAIL PROTECTED]> Sent: Sunday, March 02, 2008 2:34 PM To: Subject: Re: [VOTE] Pass-by-value related SPI change Raymond Feng wrote: Hi, Please vote on one of the following five options to define allowsPassByReference property for Invokers. You can vote with multiple choices ordered by your preference. [1] Add "boolean allowsPassByReference()" to the Invoker interface directly [2] Add "boolean allowsPassByReference()" to an optional SPI (either a separate interface or a sub-interface of Invoker) [3] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", change the Provider.createInvoker() to take InvokerProperties. Add "getInvokerProperties()" to the Invoker interface. [4] Define an "InvokerProperties" class to encapsulate known properties including "allowsPassByReference", add "getInvokerProperties()" to the Invoker interface. [5] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", define an "InvocationPropertiesFactory" interface to create "InvokerProperties", add "getInvokerProperties()" to the Invoker interface. My vote is [1], [2]. Thanks, Raymond Despite my request in [1], the option I proposed in [2] has not been included in this vote. It may be that option [5] was intended to be this option, but as stated here it has significant differences from my proposal. I'd like to request that this vote be withdrawn and restarted with the option I proposed in [2] included. To avoid any possible ambiguity, here is the summary wording for this option. [n] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", add an "InvokerProperties" parameter to the createInvoker() method, and add "getInvokerProperties()" to the Invoker interface. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28294.html [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28086.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Pass-by-value related SPI change
Isn't option [3] on the vote the same as your [n]? [3] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", change the Provider.createInvoker() to take InvokerProperties. Add "getInvokerProperties()" to the Invoker interface. [n] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", add an "InvokerProperties" parameter to the createInvoker() method, and add "getInvokerProperties()" to the Invoker interface. Thanks, Raymond -- From: "Simon Nash" <[EMAIL PROTECTED]> Sent: Sunday, March 02, 2008 2:34 PM To: Subject: Re: [VOTE] Pass-by-value related SPI change Raymond Feng wrote: Hi, Please vote on one of the following five options to define allowsPassByReference property for Invokers. You can vote with multiple choices ordered by your preference. [1] Add "boolean allowsPassByReference()" to the Invoker interface directly [2] Add "boolean allowsPassByReference()" to an optional SPI (either a separate interface or a sub-interface of Invoker) [3] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", change the Provider.createInvoker() to take InvokerProperties. Add "getInvokerProperties()" to the Invoker interface. [4] Define an "InvokerProperties" class to encapsulate known properties including "allowsPassByReference", add "getInvokerProperties()" to the Invoker interface. [5] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", define an "InvocationPropertiesFactory" interface to create "InvokerProperties", add "getInvokerProperties()" to the Invoker interface. My vote is [1], [2]. Thanks, Raymond Despite my request in [1], the option I proposed in [2] has not been included in this vote. It may be that option [5] was intended to be this option, but as stated here it has significant differences from my proposal. I'd like to request that this vote be withdrawn and restarted with the option I proposed in [2] included. To avoid any possible ambiguity, here is the summary wording for this option. [n] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", add an "InvokerProperties" parameter to the createInvoker() method, and add "getInvokerProperties()" to the Invoker interface. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28294.html [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28086.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Pass-by-value related SPI change
Raymond Feng wrote: Hi, Please vote on one of the following five options to define allowsPassByReference property for Invokers. You can vote with multiple choices ordered by your preference. [1] Add "boolean allowsPassByReference()" to the Invoker interface directly [2] Add "boolean allowsPassByReference()" to an optional SPI (either a separate interface or a sub-interface of Invoker) [3] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", change the Provider.createInvoker() to take InvokerProperties. Add "getInvokerProperties()" to the Invoker interface. [4] Define an "InvokerProperties" class to encapsulate known properties including "allowsPassByReference", add "getInvokerProperties()" to the Invoker interface. [5] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", define an "InvocationPropertiesFactory" interface to create "InvokerProperties", add "getInvokerProperties()" to the Invoker interface. My vote is [1], [2]. Thanks, Raymond Despite my request in [1], the option I proposed in [2] has not been included in this vote. It may be that option [5] was intended to be this option, but as stated here it has significant differences from my proposal. I'd like to request that this vote be withdrawn and restarted with the option I proposed in [2] included. To avoid any possible ambiguity, here is the summary wording for this option. [n] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", add an "InvokerProperties" parameter to the createInvoker() method, and add "getInvokerProperties()" to the Invoker interface. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28294.html [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28086.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Pass-by-value related SPI change
My vote is for [2], [1] Thanks - Venkat On Sat, Mar 1, 2008 at 5:14 AM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > Please vote on one of the following five options to define > allowsPassByReference property for Invokers. You can vote with multiple > choices ordered by your preference. > > [1] Add "boolean allowsPassByReference()" to the Invoker interface > directly > > [2] Add "boolean allowsPassByReference()" to an optional SPI (either a > separate interface or a sub-interface of Invoker) > > [3] Define an "InvokerProperties" interface to encapsulate known > properties > including "allowsPassByReference", change the Provider.createInvoker() to > take InvokerProperties. Add "getInvokerProperties()" to the Invoker > interface. > > [4] Define an "InvokerProperties" class to encapsulate known properties > including "allowsPassByReference", add "getInvokerProperties()" to the > Invoker interface. > > [5] Define an "InvokerProperties" interface to encapsulate known > properties > including "allowsPassByReference", define an "InvocationPropertiesFactory" > interface to create "InvokerProperties", add "getInvokerProperties()" to > the > Invoker interface. > > My vote is [1], [2]. > > Thanks, > Raymond > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] Pass-by-value related SPI change
Raymond Feng wrote: Hi, Please vote on one of the following five options to define allowsPassByReference property for Invokers. You can vote with multiple choices ordered by your preference. [1] Add "boolean allowsPassByReference()" to the Invoker interface directly [2] Add "boolean allowsPassByReference()" to an optional SPI (either a separate interface or a sub-interface of Invoker) [3] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", change the Provider.createInvoker() to take InvokerProperties. Add "getInvokerProperties()" to the Invoker interface. [4] Define an "InvokerProperties" class to encapsulate known properties including "allowsPassByReference", add "getInvokerProperties()" to the Invoker interface. [5] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", define an "InvocationPropertiesFactory" interface to create "InvokerProperties", add "getInvokerProperties()" to the Invoker interface. My vote is [1], [2]. Thanks, Raymond My vote is [1], [2]. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Pass-by-value related SPI change
Hi, Please vote on one of the following five options to define allowsPassByReference property for Invokers. You can vote with multiple choices ordered by your preference. [1] Add "boolean allowsPassByReference()" to the Invoker interface directly [2] Add "boolean allowsPassByReference()" to an optional SPI (either a separate interface or a sub-interface of Invoker) [3] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", change the Provider.createInvoker() to take InvokerProperties. Add "getInvokerProperties()" to the Invoker interface. [4] Define an "InvokerProperties" class to encapsulate known properties including "allowsPassByReference", add "getInvokerProperties()" to the Invoker interface. [5] Define an "InvokerProperties" interface to encapsulate known properties including "allowsPassByReference", define an "InvocationPropertiesFactory" interface to create "InvokerProperties", add "getInvokerProperties()" to the Invoker interface. My vote is [1], [2]. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
