Maskim,
> I propose to keep the user path for creating caches consistent for Ignite > nodes and thin clients, because that is how it is done for all other > settings today. 1. We already have some inconsistency between nodes and thin clients (ClientCache has some difference with IgniteCache, ClientConfiguration is absolutely different to IgniteConfiguration, ClientCacheConfiguration has some difference with CacheConfiguration, etc). So "how it is done for all other settings" is not correct. 2. As I said before, your proposal has nothing to do with maintaining consistency. In node configuration we provide configured affinity. In thin client configuration we provide some parameters for affinity. It's absolutely different from the user's point of view. For example, the user can't just replace CacheConfiguration with ClientCacheConfiguration and don't change other code parts. Code related to affinity still needs to be rewritten. If so, why is it better than just "partitions count"? It has the same disadvantages (API inconsistency), but "partitions count" is simpler. Affinity configuration looks like a redundant entity, which can contain only one parameter "partitions count". 3. setExcludedNeighbors it's not a part of the affinity function interface, it's part of Rendezvous Affinity implementation (as far as node filters, backup filters, etc). If we want these parameters, it's better to provide stateful serialization of affinity (not just affinity configuration).
