How about separating our JCache implementation from the core of the probuct.
Currently IgniteCache is the heart of Ignite. It is the basic storage unit. At the same time, it is the direct implementation of the JCache API, and some of the JCache features align somewhat awkwardly with Ignite concepts. Would be nice to have something like IgniteSpace as our core component, and have other components built on top of it as wrappers providing various APIs. For example - IgniteSpace itself is a distributed storage unit, that is partitioned, that has affinity, etc; note that it doesn’t have to have ANY particular API to add data, even key-value - IgniteCache is a wrapper around IgniteSpace that allows to store key-value pairs and implements JCache API - IgniteSql (we’re doing it eventually, right?) is a wrapper around IgniteSpace that allows to store SQL tables and implements ANSI SQL - IgniteQueue is a wrapper that implements Queue and so on. WDYT? Stan From: Ilya Lantukh Sent: 15 октября 2018 г. 14:49 To: dev@ignite.apache.org Subject: Applicability of term 'cache' to Apache Ignite Hi Igniters, I would like to rise a question how we use the term *'cache'* in Ignite and how it corresponds to terminology in IT industry in general. >From wikipedia: In computing <https://en.wikipedia.org/wiki/Computing>, a *cache* /kæʃ/ <https://en.wikipedia.org/wiki/Help:IPA/English> *kash* <https://en.wikipedia.org/wiki/Help:Pronunciation_respelling_key>, is a hardware or software component that stores data so that future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation or a copy of data stored elsewhere. [1] When the first version of Ignite was released, this term was correct. We positioned Ignite mostly as an intermediate storage layer between application and a database, designed to make data access faster. However, since addition of native persistence we started to call Ignite a "memory-centric database", and as far as I know, some organizations now use it as a primary data storage, without underlying database. In this case, calling our storage unit a *'cache'* causes unnecessary confusion. Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that would fit both use-cases. Personally I like the term IgniteSpace. [1] https://en.wikipedia.org/wiki/Cache_(computing) -- Best regards, Ilya
