"Apache Ignite" will remain the same... We are just going to refer to it as "IgniteDB" everywhere where it doesn't technically conflict with "Apache Ignite". We are also not changing the package structure (i.e. the packaging will remain 'org.apache.ignite.xxx').
Or... we can go and rename the project to "Apache IgniteDB" which is a longer process but the community has plenty of time to do it in "ignite 3.0" timeframe. I'd love to hear other's opinions on that. Thanks, -- Nikita Ivanov On Thu, Sep 24, 2020 at 11:44 AM Denis Magda <dma...@apache.org> wrote: > Nikita, Cos, > > Agree, IgniteDB would be a much better option if the project would be > launched these days with the current set of capabilities. But, as of now, > the renaming won't be a benign move, it can do more bad than good. "Apache > Ignite" is already a brand and even a trademark, the organic traffic is > high and the word-of-mouth is ramping up. So, it doesn't make sense from a > marketing standpoint. Also, regardless of the name you still need to define > your database - whether it's columnar, in-memory, memory-X, > extraterrestrial, or interstellar, or whatever. Anyway, I believe that > Ignite can easily pivot without the name change. > > - > Denis > > > On Tue, Sep 22, 2020 at 11:49 AM Konstantin Boudnik <c...@apache.org> > wrote: > > > +1 > > > > With regards, > > Cos > > > > On 2020-09-21 20:35, Nikita Ivanov wrote: > > > My vote is to just call ignite "IgniteDB". That's it. No other > additional > > > explanation is required as no amount of additional verbiage will help. > > > Every DB is different: from MongoDB, to RedisDB, to CockroachDB, to > > Oracle > > > - they all look & act completely different, and they don't go around > > trying > > > to explain in one line what they do and how they are different. > > > > > > "IgniteDB" is clear, concise and gives us the broadest initial > acceptance > > > from the new user perspective. > > > > > > Thanks, > > > -- > > > Nikita Ivanov > > > > > > > > > > > > On Sat, Sep 19, 2020 at 1:10 PM Saikat Maitra <saikat.mai...@gmail.com > > > > > wrote: > > > > > >> Hi, > > >> > > >> My thoughts are similar to as Denis and Val mentioned like Apache > > Ignite - > > >> "A Memory Centric Database". > > >> > > >> It aligns to current features of Apache Ignite as mentioned in the > below > > >> post. > > >> > > >> > > >> > > > https://thenewstack.io/memory-centric-architectures-whats-next-for-in-memory-computing > > >> > > >> Regards, > > >> Saikat > > >> > > >> On Fri, Sep 18, 2020 at 9:02 AM Carbone, Adam < > > adam.carb...@bottomline.com> > > >> wrote: > > >> > > >>> So when I came across Ignite It was described as an In Memory Data > Grid > > >>> > > >>> So one way to look at this is who do you fashion as Ignite competing > > >>> against? > > >>> > > >>> Are competing against Redis, Aerospike - In Memory Databases > > >>> > > >>> Or are you more competing with > > >>> > > >>> Gigaspaces - True In memory Compute platform > > >>> > > >>> And then you have like of > > >>> > > >>> Hazelcast that started as a Distributed Hash and have gained some > > >>> features... > > >>> > > >>> On thing that I think is a differentiator that isn't being > highlighted > > >>> but Is unique feature to Ignited, and the primary reason we ended up > > here; > > >>> The integration with spark and it's distributed/shared > > Datasets/Dataframes. > > >>> > > >>> I don't know for me the In Memory Data Grid I think fits what Ignite > > >>> is... > > >>> > > >>> Regards > > >>> > > >>> ~Adam > > >>> > > >>> Adam Carbone | Director of Innovation – Intelligent Platform Team | > > >>> Bottomline Technologies > > >>> Office: 603-501-6446 | Mobile: 603-570-8418 > > >>> www.bottomline.com > > >>> > > >>> > > >>> > > >>> On 9/17/20, 11:45 AM, "Glenn Wiebe" <glenn.wi...@gridgain.com> > wrote: > > >>> > > >>> I agree with Stephen about "database" devaluing what Ignite can > do > > >>> (though > > >>> it probably hits the majority of existing use cases). I tend to > go > > >>> with > > >>> "massively distributed storage and compute platform" > > >>> > > >>> I know, I didn't take sides, I just have both. > > >>> > > >>> Cheers, > > >>> Glenn > > >>> > > >>> On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, < > > >>> stephen.darling...@gridgain.com> wrote: > > >>> > > >>> > I think this is a great question. Explaining what Ignite does > is > > >>> always a > > >>> > challenge, so having a useful “tag line” would be very > valuable. > > >>> > > > >>> > I’m not sure what the answer is but I think calling it a > > “database” > > >>> > devalues all the compute facilities. "Computing platform” may > be > > >>> too vague > > >>> > but it at least says that we do more than “just” store data. > > >>> > > > >>> > On 17 Sep 2020, at 06:29, Valentin Kulichenko < > > >>> > valentin.kuliche...@gmail.com> wrote: > > >>> > > > >>> > My vote is for the "distributed memory-first database". It > > clearly > > >>> states > > >>> > that Ignite is a database (which is true at this point), while > > still > > >>> > emphasizing the in-memory computing power endorsed by the > > platform. > > >>> > > > >>> > The "in-memory computing platform" is an ambiguous term and > > doesn't > > >>> really > > >>> > reflect what Ignite is, especially in its current state. > > >>> > > > >>> > -Val > > >>> > > > >>> > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda < > dma...@apache.org> > > >>> wrote: > > >>> > > > >>> >> Igniters, > > >>> >> > > >>> >> Throughout the history of our project, we could see how the > > >>> addition of > > >>> >> certain features required us to reassess the project's name > and > > >>> category. > > >>> >> > > >>> >> Before Ignite joined the ASF, it supported only compute APIs > > >>> resembling > > >>> >> the > > >>> >> MapReduce engine of Hadoop. Those days, it was fair to define > > >>> Ignite as "a > > >>> >> distributed in-memory computing engine". Next, at the time of > > the > > >>> project > > >>> >> donation, it already included key-value/SQL/transactional > APIs, > > >>> was used > > >>> >> as > > >>> >> a distributed cache, and significantly outgrew the "in-memory > > >>> computing > > >>> >> engine" use case. That's how the project transitioned to the > > >>> product > > >>> >> category of in-memory caches and we started to name it as an > > >>> "in-memory > > >>> >> data grid" or "in-memory computing platform" to differentiate > > from > > >>> >> classical caching products such as Memcached and Redis. > > >>> >> > > >>> >> Nowadays, the project outgrew its caching use case, and the > > >>> classification > > >>> >> of Ignite as an "in-memory data grid" or "in-memory computing > > >>> platform" > > >>> >> doesn't sound accurate. We rebuilt our storage engine by > > replacing > > >>> a > > >>> >> typical key-value engine with a B-tree engine that spans > across > > >>> memory and > > >>> >> disk tiers. And it's not surprising to see more deployments > of > > >>> Ignite as a > > >>> >> database on its own. So, it feels like we need to reconsider > > Ignite > > >>> >> positioning again so that a) application developers can > > discover > > >>> it easily > > >>> >> via search engines and b) the project can stand out from > > in-memory > > >>> >> projects > > >>> >> with intersecting capabilities. > > >>> >> > > >>> >> To the point, I'm suggesting to reposition Ignite in one of > the > > >>> following > > >>> >> ways: > > >>> >> > > >>> >> 1. Ignite is a "distributed X database". We are indeed a > > >>> distributed > > >>> >> partitioned database where X can be "multi-tiered" or > > >>> "memory-first" to > > >>> >> emphasize that we are more than an in-memory database. > > >>> >> 2. Keep defining Ignite as "an in-memory computing > platform" > > >>> but name > > >>> >> our storage engine uniquely as "IgniteDB" to highlight > that > > the > > >>> >> platform is > > >>> >> powered by a "distributed multi-tiered/memory-first > > database". > > >>> >> > > >>> >> What is your thinking? > > >>> >> > > >>> >> > > >>> >> (Also, regardless of a selected name, Ignite still will be > > used as > > >>> a cache > > >>> >> and grid, and we're not going to stop appealing to those use > > >>> cases. But > > >>> >> those are just use cases while Ignite has to figure out its > new > > >>> identity > > >>> >> ... again). > > >>> >> > > >>> >> > > >>> >> - > > >>> >> Denis > > >>> >> > > >>> > > > >>> > > > >>> > > > >>> > > >>> > > > > > >
