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