Big changes for .NET:
* Remove legacy Entity Framework integration
* Remove legacy ASP.NET integration
* Move from .NET Framework 4.0 (released in 2010) to .NET Standard 2.0
(modern way to build libraries)

Thanks,
Pavel

On Mon, Jun 17, 2019 at 7:14 PM Igor Sapego <isap...@gridgain.com> wrote:

> For the C++ I propose to drop support of VS 2010 and move to
> at least 2012 (or, better yet 2013).
>
> Also, I'd drop x86 support for everything except for maybe ODBC.
>
> Best Regards,
> Igor
>
> On Mon, Jun 17, 2019 at 7:12 PM Pavel Kovalenko <jokse...@gmail.com>
> wrote:
>
> > I would like to add to the list following:
> >
> > 1. Remove ForceKeyRequests and related code. Since we have Late affinity
> > assignment and primary node partitions are always up to date we don't
> need
> > to request actual data from backups.
> > 2. Remove @CentralizedAffinityFunction and related code. I don't see any
> > real usages of custom affinity functions that use this annotation.
> > 3. Leave Exchanges Merge + Late Affinity assignment as the only PME
> > protocol. Remove centralized affinity distribution in case of node left
> and
> > no merge exchange legacy modes.
> > 4. Remove CacheRebalanceMode.NONE and Rebalance Delay as it can break
> data
> > consistency in a cluster. Also, remove force rebalance mode as it can be
> > used only if rebalance delay is set.
> >
> > пн, 17 июн. 2019 г. в 18:39, Dmitriy Pavlov <dpav...@apache.org>:
> >
> > > Nikolay,
> > >
> > > we can (and probably should) discuss stop deploying caches/services to
> > > client nodes.
> > >
> > > But I would not name it removal of client nodes at all. Any Apache
> Ignite
> > > guide I saw is starting from 2 steps: 1) start server node, 2) start
> > client
> > > node.
> > >
> > > There are no reasons to write software if users are unaware of how to
> use
> > > it. So I do not agree that supplementary materials are unimportant.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <nizhi...@apache.org>:
> > >
> > > > Dmitriy,
> > > >
> > > > I think the whole concept of "client" nodes is broken.
> > > > And that's why:
> > > >
> > > > Ignite Client node nothing to do with "client" :)
> > > > We can deploy cache on it, we can execute compute tasks, services on
> > it.
> > > > "client node" is a node with special join process and some
> > rebalance/PME
> > > > hacks.
> > > > And we put many(many!) efforts to support this concept and this
> hacks.
> > > >
> > > > And I'm asking: What value client nodes bring to Ignite?
> > > >
> > > > I think, Alexey, already answered correctly:
> > > >
> > > > * Transactions support.
> > > > * P2P deployment.
> > > >
> > > > I think we should, definitely, remove concept of "client nodes" in
> the
> > > > future.
> > > > It's about product design decision, in the first place, not about
> > > > additional materials.
> > > >
> > > > The simpler core codebase we have, the more reliable product we ca
> > build
> > > > with it.
> > > >
> > > >
> > > > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:
> > > > > Hi Nikolay,
> > > > >
> > > > > I think client nodes removal is not possible in the near future
> > because
> > > > of
> > > > > tons of usages everywhere outside Ignite code (in products, guides,
> > > > books,
> > > > > training, etc.)
> > > > >
> > > > > If we have replacement we should encourage users to migrate, but we
> > > can't
> > > > > remove such a core feature.
> > > > >
> > > > > Alexey, sure we can discuss removal of modules, why not?
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <
> zaleslaw....@gmail.com
> > >:
> > > > >
> > > > > > Could we suggest here remove whole modules?
> > > > > >
> > > > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com
> > > > > > > :
> > > > > > > Nikolay,
> > > > > > >
> > > > > > > I had this thought too, but I am not too eager to implement it
> > yet.
> > > > The
> > > > > > > reason is transaction protocol complexity/performance issues
> with
> > > > thin
> > > > > > > clients.
> > > > > > >
> > > > > > > A thick client can communicate with each primary node and
> > > coordinate
> > > > > > > prepare/commit phases. Thin client can only communicate with
> one
> > > > node, so
> > > > > > > the change will mean an additional network hop. Of course, we
> can
> > > > make
> > > > > >
> > > > > > thin
> > > > > > > clients implement the same protocol, but it will immediately
> > > > increase the
> > > > > > > protocol complexity for all platforms.
> > > > > > >
> > > > > > > Plus, we do not have near cache on thin clients, we do not
> > support
> > > > p2p
> > > > > > > class deployment, etc. Since thin clients are positioned as
> > > > > > > platform-agnostic, I do not think it makes sense to expose all
> > > > feature
> > > > > >
> > > > > > set
> > > > > > > of Igntie to thin clients.
> > > > > > >
> > > > > > > Instead, we can significantly simplify client node
> configuration
> > -
> > > it
> > > > > > > currently requires the same config as a regular Ignite node,
> > > > however, in
> > > > > > > most cases, the configuration can be reduced almost to a
> several
> > > > > >
> > > > > > host:port
> > > > > > > pairs.
> > > > > > >
> > > > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <
> > nizhi...@apache.org
> > > >:
> > > > > > >
> > > > > > > > Alexey.
> > > > > > > >
> > > > > > > > I want to share a thought (just don't drop it out in one
> moment
> > > :)
> > > > ).
> > > > > > > >
> > > > > > > > Do we really need "client nodes"?
> > > > > > > >
> > > > > > > > We have thin client protocol that is a very convenient point
> to
> > > > > >
> > > > > > interact
> > > > > > > > with Ignite.
> > > > > > > > So, why, we need one more entity and work mode such as
> "client
> > > > node"?
> > > > > > > >
> > > > > > > > From my point of view, client nodes were required in the time
> > > > without a
> > > > > > > > thin client.
> > > > > > > > Now, we have it.
> > > > > > > >
> > > > > > > > Let's simplify Ignite codebase and drop client nodes!
> > > > > > > >
> > > > > > > > How does it sound?
> > > > > > > >
> > > > > > > >
> > > > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > > > > > > Nikolay,
> > > > > > > > >
> > > > > > > > > Local caches and scalar are already in the list :) Added
> the
> > > > outdated
> > > > > > > > > metrics point.
> > > > > > > > >
> > > > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <
> > > > nizhi...@apache.org>:
> > > > > > > > >
> > > > > > > > > > * Scalar.
> > > > > > > > > > * LOCAL caches.
> > > > > > > > > > * Deprecated metrics.
> > > > > > > > > >
> > > > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > > > > > > > > Igniters,
> > > > > > > > > > >
> > > > > > > > > > > Even though we are still planning the Ignite 2.8
> > release, I
> > > > would
> > > > > > > >
> > > > > > > > like to
> > > > > > > > > > > kick-off a discussion related to Ignite 3.0, because
> the
> > > > efforts
> > > > > > >
> > > > > > > for
> > > > > > > > AI
> > > > > > > > > >
> > > > > > > > > > 3.0
> > > > > > > > > > > will be significantly larger than for AI 2.8, better to
> > > start
> > > > > > >
> > > > > > > early.
> > > > > > > > > > >
> > > > > > > > > > > As a first step, I would like to discuss the list of
> > things
> > > > to be
> > > > > > > >
> > > > > > > > removed
> > > > > > > > > > > in Ignite 3.0 (partially this thread is inspired by
> Denis
> > > > Magda's
> > > > > > > >
> > > > > > > > IGFS
> > > > > > > > > > > removal thread). I've separated all to-be-removed
> points
> > > from
> > > > > > > >
> > > > > > > > existing
> > > > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and also
> > added
> > > > a few
> > > > > > > >
> > > > > > > > more
> > > > > > > > > > > things that look right to be dropped.
> > > > > > > > > > >
> > > > > > > > > > > Please share your thoughts, probably, there are more
> > > outdated
> > > > > > >
> > > > > > > things
> > > > > > > > we
> > > > > > > > > > > need to add to the wishlist.
> > > > > > > > > > >
> > > > > > > > > > > As a side question: I think it makes sense to create
> > > tickets
> > > > for
> > > > > > >
> > > > > > > such
> > > > > > > > > > > improvements, how do we track them. Will the 3.0
> version
> > > > suffice
> > > > > >
> > > > > > or
> > > > > > > > > >
> > > > > > > > > > should
> > > > > > > > > > > we add a separate label?
> > > >
> > >
> >
>

Reply via email to