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" <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
>> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
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]
