See inline.
Simon
Raymond Feng wrote:
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.
I thought my proposal (see [1]) was a reasonable compromise that provided
stability without making too much of an architectural mess. There is a
one-time compatibilty hit to introduce the new approach, though. I'd be
interested to know what others think of this.
Simon
[1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL
PROTECTED]
Thanks,
Raymond
----- Original Message ----- From: "ant elder" <[EMAIL PROTECTED]>
To: <[email protected]>
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: <[email protected]>
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: <[email protected]>
>> 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]
