[DISCUSSION] Renaming Ignite's product category

[Valentin Kulichenko]

Hi Denis,

Correct me if I'm wrong, but it sounds like you interpret the term
"database" as just storage, separating it from processing capabilities. I
would disagree with that. *Any* database provides such capabilities. Even
traditional relational databases, which are based on SQL, allow you to do
filtering, aggregations, and other stuff on the server side. Not to mention
that there are also triggers, stored procedures, and other features.

On its own, the fact that Apache Ignite has computational APIs doesn't make
the product unique. The uniqueness comes from specific APIs and features it
provides.

That said, calling Ignite a database seems absolutely fair to me. As a
matter of fact, when I talk about Ignite, I usually describe it as "a
database that allows you to ...", where I typically fill the
blanks depending on who I talk to, what the use case might be, etc.

I'm OK with calling the product "Ignite Database" or "IgniteDB". If we
follow this route, what are the changes we will need to make? Will it only
affect the website and documentation? I can't think of any code changes
that might be required.

-Val

On Thu, Sep 24, 2020 at 12:01 PM Denis Magda <[hidden email]> wrote:

> If "Apache Ignite" remains then another option is to keep defining Ignite
> as an in-memory computing platform that is shaped by two essential
> components:
>
>    - IgniteDB - unique storage engine
>    - compute layer which is basically our APIs.
>
> Also, check Mongo that titled its latest storage engine as WiredTiger to
> highlight the uniqueness, that there is something special about it, urging
> you to go ahead and look into (the same move should work for the Ignite
> platform that is powered the IgniteDB database/storage engine):
> https://docs.mongodb.com/manual/core/storage-engines/
>
> Just another idea into this melting pot.
>
>
> -
> Denis
>
>
> On Thu, Sep 24, 2020 at 11:51 AM Nikita Ivanov <[hidden email]>
> wrote:
>
> > "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 <[hidden email]> 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 <[hidden email]>
> > > 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 <
> > [hidden email]
> > > >
> > > > > 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 <
> > > > [hidden email]>
> > > > >> 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: [phone]
> > > > >>> www.bottomline.com
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]>
> > > 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, <
> > > > >>>      [hidden email]> 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 <
> > > > >>>      > [hidden email]> 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 <
> > > [hidden email]>
> > > > >>> 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
> > > > >>>      >>
> > > > >>>      >
> > > > >>>      >
> > > > >>>      >
> > > > >>>
> > > > >>>
> > > > >
> > > >
> > >
> >
>

[dmagda]

Apache Ignite is a trademark in the U.S. and we're still working to get it
registered in China. It's a long process that can span years. It took us
years. Not to say about all the content that is published and indexed for
the "Apache Ignite" term. These are the two primary reasons why I don't
support the idea of renaming the project into "IgniteDB" or anything else.
Plus, I don't believe that it will be a game-changer. Kafka, Hadoop, Redis,
Spark don't have any special additions in their name and that didn't bar
them from climbing to the mountain peak.

-
Denis


On Fri, Oct 2, 2020 at 3:49 PM Valentin Kulichenko <
[hidden email]> wrote:

> Hi Denis,
>
> Correct me if I'm wrong, but it sounds like you interpret the term
> "database" as just storage, separating it from processing capabilities. I
> would disagree with that. *Any* database provides such capabilities. Even
> traditional relational databases, which are based on SQL, allow you to do
> filtering, aggregations, and other stuff on the server side. Not to mention
> that there are also triggers, stored procedures, and other features.
>
> On its own, the fact that Apache Ignite has computational APIs doesn't make
> the product unique. The uniqueness comes from specific APIs and features it
> provides.
>
> That said, calling Ignite a database seems absolutely fair to me. As a
> matter of fact, when I talk about Ignite, I usually describe it as "a
> database that allows you to ...", where I typically fill the
> blanks depending on who I talk to, what the use case might be, etc.
>
> I'm OK with calling the product "Ignite Database" or "IgniteDB". If we
> follow this route, what are the changes we will need to make? Will it only
> affect the website and documentation? I can't think of any code changes
> that might be required.
>
> -Val
>
> On Thu, Sep 24, 2020 at 12:01 PM Denis Magda <[hidden email]> wrote:
>
> > If "Apache Ignite" remains then another option is to keep defining Ignite
> > as an in-memory computing platform that is shaped by two essential
> > components:
> >
> >    - IgniteDB - unique storage engine
> >    - compute layer which is basically our APIs.
> >
> > Also, check Mongo that titled its latest storage engine as WiredTiger to
> > highlight the uniqueness, that there is something special about it,
> urging
> > you to go ahead and look into (the same move should work for the Ignite
> > platform that is powered the IgniteDB database/storage engine):
> > https://docs.mongodb.com/manual/core/storage-engines/
> >
> > Just another idea into this melting pot.
> >
> >
> > -
> > Denis
> >
> >
> > On Thu, Sep 24, 2020 at 11:51 AM Nikita Ivanov <[hidden email]>
> > wrote:
> >
> > > "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 <[hidden email]>
> 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 <[hidden email]>
> > > > 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 <
> > > [hidden email]
> > > > >
> > > > > > 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 <
> > > > > [hidden email]>
> > > > > >> 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: [phone]
> > > > > >>> www.bottomline.com
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]
> >
> > > > 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, <
> > > > > >>>      [hidden email]> 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 <
> > > > > >>>      > [hidden email]> 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 <
> > > > [hidden email]>
> > > > > >>> 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
> > > > > >>>      >>
> > > > > >>>      >
> > > > > >>>      >
> > > > > >>>      >
> > > > > >>>
> > > > > >>>
> > > > > >
> > > > >
> > > >
> > >
> >
>