ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Merging all network components to a single one
Date Sat, 11 Mar 2017 01:07:45 GMT
Agree with Denis. It is not practical to remove any existing SPIs unless we
come up with proper TCP SPI design and implementation.

I think it will be enough to simply deprecate the existing SPIs we plan to
remove, without physically removing them, until the design is finalized.

D.

On Fri, Mar 10, 2017 at 11:55 AM, Denis Magda <dmagda@apache.org> wrote:

> > 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 <yzhdanov@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message