Folks,
I tend to favour this more conservative approach. There may be a
problem longer term in explaining the interfaces to writers of new
binding types and implementation types, but the mess caused to existing
implementation types and existing binding types by breaking changes in
the SPI is not worth it, based on my experiences.
My 2 cents,
Mike.
ant elder wrote:
On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote:
<snip>
1. Not including the change to remove the redundant isCallback parameter
from ReferenceBindingProvider.createInvoker() doesn't cause any
significant problems in the core. The core can always pass the
meaningless extra parameter, and the providers can always ignore it.
This does incur the collateral rework costs that I mentioned above
for when we get around to cleaning this one up.
+1, this sounds a good approach to me
2. Not including the supportsAsyncOneWayInvocation() methods on
ReferenceBindingProvider and ServiceBindingProvider presents a bit
more of a challenge. One possibility is to create a new marker
interface that can be implemented by providers that support
asynchronous one-way invocation. The core could test for this marker
interface and omit the thread switch if the provider implements it.
I'm not really convinced that this is cleaner (it's probably a bit
more tricky to explain than just having methods for this as we do
everywhere else in the SPI), but it would get around the need for a
breaking SPI change now. What do people think about this approach?
+1, I like it a lot
3. Not including the createCallbackInvoker() method on
ServiceBindingProvider.
seems at first sight to make it impossible for callbacks to work.
But there is (as always with software) another way. We could
introduce
a new interface ServiceBindingCallbackProvider that extends
ServiceBindingProvider and adds the createCallbackInvoker() method.
Providers that support callbacks would implement this interface,
and providers that don't support callbacks could continue to
implement ServiceBindingProvider. Again, this seems slightly tricky
but it would work and it wouldn't need a breaking SPI change.
+1 again
Now I'll circle back to 1 again. The proposal for 3 has inspired me
to imagine a new interface that just contains the new method signature
for createInvoker(). New providers can implement this interface and
the new signature, and old providers can continue with the old signature,
with the core being smart enough to understand both forms and call the
signature that is available.
Another +1
<snip>
My opinion is that the long term solution is likely
to be the one I have currently implemented, so the work to change other
affected code will need to be done anyway at some point.
I also agree the end result is likely to be similar but IMHO the
benefits of
keeping things separate and stable for the time being far out way the extra
work of at some point cleaning up all the SPIs (which we're going to
have to
do anyway).
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
