See responses inline below.
Simon
Jean-Sebastien Delfino wrote:
Simon Nash wrote:
I'm wondering whether it would be good to have a vote about this.
Of the five people who have expressed a view on this so far, four
of them have had a different first preference. In the interests
of making progress, I think it might be good to put forward a set
of options and vote to choose between them.
One question of clarification inline below.
...
>> Jean-Sebastien Delfino wrote:
My preference:
1. (1) above add a method to Invoker, and ask people on our dev and
user mailing lists if they have any issues with it.
2. (2) above and a plan to merge all these Xyz2 interfaces into the
main interfaces in the next major release.
> Simon Nash wrote:
By the "next major release" do you mean the 1.2 release that we recently
started discussing, or something else?
Difficult to say until more discussion shapes 1.2 :) I mean major enough
to introduce significant SPI changes.
3. Simon's proposal [1], which introduces too much complexity IMHO.
A few more concerns with that proposal:
- It introduces a breaking change as well.
There is a one-time breakage that prevents the need to ever break
compatibility to add more properties in the future. If we ever need
to add more properties beyond the current one that we are discussing
(very likely!), this is a win compared to other approaches that break
with every new property.
- An extension developer will have to work with two objects instead of
one. The same technique applied to other extension points (provider,
artifactprocessor, resolver) will double the number of interfaces.
There is no increase in the total "surface area" of the SPI in terms
of methods. This approach simply separates properties from functional
methods by putting them on different interfaces.
- Ownership and lifecycle of InvokerProperties are unclear. I don't see
why an Invoker should return InvokerProperties if it's already passed to
it. I don't understand when an Invoker should initialize that properties
object.
Ownership of the InvokerProperties object transfers to the invoker object
when the invoker object is created. (This is why the invoker object
returns the InvokerProperties object.) When the invoker object is
destroyed, the InvokerProperties dies with it (by normal Java GC).
This all seems straightforward and clear to me.
- Unless I'm missing something, it will require a breaking change to
Provider.createInvoker() to pass an InvokerProperties, or a dependency
on a Tuscany InvokerProperties implementation class.
As discussed above, there is a one-time breaking change to introduce
the new approach. InvokerProperties is an interface, so there is no
dependency on a Tuscany InvokerProperties implementation class.
- If InvokerProperties is an interface then an extension developer can
implement it, and will be broken again as soon as a new property is added.
VERY IMPORTANT... SPIs are of two different kinds, those that extensions
implement (like xxxProvider) and those that extensions use (like Message).
For the "extensions implement" kind, new methods cannot be added without
breakage. For the "extensions use" kind, new methods can be added without
breakage. This is a fundamental difference in terms of the ability to
support compatible evolution. However, it is not a difference that we
have highlighted in our current SPI design or documentation.
The reason we have the current problem is that invoker and provider
properties have been placed on "extensions implement" SPIs. For compatible
evolution, they should be placed on "extensions use" SPIs instead.
My proposal moves these properties from "extensions implement" SPIs to
"extensions use" SPIs. InvokerProperties would be an "extensions use" SPI
that should not be implemented by extension developers.
- The InvokerProperties pattern does not address the bigger issue of all
changes to other extension methods (createInvoker, or just the invoke
method itself).
Neither do any of the other proposals that have been put forward.
The fundamental question remains: Can we add methods to an interface
implemented by an extension? and my opinion is:
- Yes, if the change is straightforward and publicly communicated.
I think we should take reasonable steps to avoid the need to do this
where possible. The approach I have proposed does this.
- No, if it requires significant changes to extensions. We then need
another version of the interface (like Invoker2) and support both
versions until the two interfaces get merged.
There will be some (hopefully rare) cases where changes to extensions
can't be avoided, and the xxxSPI2 approach could be used for those
changes. Alternatively, such changes could be made as part of a
major release (see below).
- It should be possible to introduce in a release SPI cleanup, merging,
refactoring and evolutions, at a reasonable pace. I am not saying that
we should do this in the upcoming 1.2 release, but I'd like to see some
SPI cleanup happen in a reasonable timeframe. They have been close to
frozen for 9 months now.
I agree that from time to time some larger SPI refactoring will be
needed, and we should have the concept of a "major release" in which
such changes would be made. Between these major releases, I think
there should be no incompatible SPI changes. I think 9 months or so
would generally be a reasonable time interval between major releases.
Simon
I'll be happy to vote on proposals though.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
