> Denis, I think we can allow this as well, but not as SPI since I want to > drop them and create 1 internal component to manage all interconnections. I > think this is enough since additions/changes will be rare and they will > result in changing internal code (including support of technologies you > mentioned). None of our users implemented discovery or communication on > their own, and I doubt if someone ever will. So, what is the purpose of > keeping SPIs?
Yasha, I don’t insist to keep the SPIs but rather want to clarify that it will be feasible to provide a custom implementation of this new networking component if needed. Looks like this will be possible. > Dmitry, you are right - this seems to be a very complex change. However, we > can we move current implementations to internal packages, introduce > configuration properties/beans so we can release and continue development > in 2.0 without breaking compatibility. Let’s do this if there is a one who can take over the interface design and complete it by 2.0 release. — Denis > On Mar 10, 2017, at 7:39 AM, Yakov Zhdanov <yzhda...@apache.org> wrote: > > Dmitry, you are right - this seems to be a very complex change. However, we > can we move current implementations to internal packages, introduce > configuration properties/beans so we can release and continue development > in 2.0 without breaking compatibility. > > Denis, I think we can allow this as well, but not as SPI since I want to > drop them and create 1 internal component to manage all interconnections. I > think this is enough since additions/changes will be rare and they will > result in changing internal code (including support of technologies you > mentioned). None of our users implemented discovery or communication on > their own, and I doubt if someone ever will. So, what is the purpose of > keeping SPIs? > > --Yakov
