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? > > > > > >
