tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/ modules/binding-ejb/src/main/java/org/apache/tus
Date Thu, 21 Feb 2008 17:32:49 GMT
I agree stability/compatibility is important. But we need to have a good 
balance here. If we always sacrifice the architectural cleaness to 
stability, we may end up with messy SPIs which will confuse our new users. 
Especially for SPIs, they are used by extension developers and embedders and 
(IMO) these types of users are more willing to use the latest code base.

Thanks,
Raymond

----- Original Message ----- 
From: "ant elder" <ant.elder@gmail.com>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, February 21, 2008 1:26 AM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca: 
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ 
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/ 
modules/binding-ejb/src/main/java/org/apache/tus


> -1 on option (1) for now as i think backward compatibility is important.
>
> It doesn't matter how trivial the fix is if a release upgrade breaks
> someones code then we may loose them as Tuscany user. We did loose users
> back in the Mx release days as we kept changing the SPIs, we made all the
> fuss about having stable SPIs for the 1.0 release and I think we should
> honour that.
>
> Note this -1 isn't a veto, just expressing an opinion.
>
>   ...ant
>
> On Tue, Feb 19, 2008 at 4:53 AM, Raymond Feng <enjoyjava@gmail.com> wrote:
>
>> +1 on Option 1) which is something I'm scared to propose these days as we
>> want to keep the SPIs binary compatible :-). I prefer to have an explict,
>> clean and strongly-typed contract.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Jean-Sebastien Delfino" <jsdelfino@apache.org>
>> To: <tuscany-dev@ws.apache.org>
>> Sent: Monday, February 18, 2008 6:50 PM
>> Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
>> itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
>> itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
>> modules/binding-ejb/src/main/java/org/apache/tus
>>
>>
>> > Raymond Feng wrote:
>> >> We could simply use Object as the return value and then cast it to the
>> >> type of the property.
>> >>
>> >> The caller code could perform the test as follows:
>> >>
>> >> if(invoker instanceof Configurable) {
>> >>    boolean allowsPBR = ((Configurable)
>> >> invoker).getProperty("AllowsPassByReference");
>> >>    if(allowsPBR) {
>> >>        // do something here
>> >>    }
>> >> }
>> >>
>> >> Thanks,
>> >> Raymond
>> >>
>> >> ----- Original Message ----- From: "Simon Nash" <nash@apache.org>
>> >> To: <tuscany-dev@ws.apache.org>
>> >> Sent: Monday, February 18, 2008 3:15 PM
>> >> Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
>> >> itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
>> >> itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
>> >> modules/binding-ejb/src/main/java/org/apache/tus
>> >>
>> >>
>> >>> Raymond Feng wrote:
>> >>>> The Configurable interface can be optionally implemented by the
>> Invoker
>> >>>> implementation classes. To support multiple properties, the invoker
>> can
>> >>>> simply do this:
>> >>>>
>> >>>> public class MyInvokerImpl implements Invoker, Configurable {
>> >>>>    ...
>> >>>>    <T> public T getProperty(String name) {
>> >>>>        if("AllowsPassByReference".equals(name) {
>> >>>>            return true;
>> >>>>        } else if("AnotherProperty".equals(name) {
>> >>>>            return "StringValue";
>> >>>>        } else {
>> >>>>            return null;
>> >>>>        }
>> >>>>    }
>> >>>> }
>> >>>>
>> >>>> This way, the property set is kept at the invoker instances.
>> >>>>
>> >>> I didn't know that generics could do this, with multiple return
>> >>> types from a single method.  (Seems like I need to go back to
>> >>> Java school!)  What does the code invoking the magical getProperty()
>> >>> method look like?
>> >>>
>> >>>   Simon
>> >
>> > Sorry, but after looking at this again I think that it's getting way 
>> > too
>> > complicated. Can we please keep this SPI simple?
>> >
>> > I'd like to propose two options:
>> >
>> > 1) Add methods to Invoker, mirroring what's described in the spec.
>> >
>> > interface Invoker {
>> >
>> >   boolean allowsPassByReference();
>> >
>> >   // and another similar method which we'll need to handle
>> >   // non-blocking calls
>> >   boolean isOneWay();
>> >
>> > }
>> >
>> > 2) or if we want to preserve binary compatibility for now, create
>> > interface Invoker2 extends Invoker {
>> >
>> >   boolean allowsPassByReference();
>> >
>> >   boolean isOneWay();
>> >
>> > }
>> >
>> > IMHO it's OK to ask Invoker implementors to add two empty methods when
>> > they port their code to the next release, so I'll prefer option (1) as
>> > it's simpler.
>> > --
>> > Jean-Sebastien
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Mime
View raw message