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
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
Let's try to simplify the project's messaging - not introduce new
sub-component naming or synthetic shelving to it :-)
--
Nikita Ivanov
On Thu, Sep 24, 2020 at 12:01 PM Denis Magda wrote:
> If "Apache Ignite" remains then another option is to keep defining Ignite
> as an in-memory computing
>
>
>
>
>
>
> *From: *Denis Magda
> *Date: *Wednesday, September 23, 2020 at 4:14 PM
> *To: *dev , "Carbone, Adam" <
> adam.carb...@bottomline.com>
> *Cc: *"u...@ignite.apache.org"
> *Subject:
*Denis Magda
> *Date: *Wednesday, September 23, 2020 at 4:14 PM
> *To: *dev , "Carbone, Adam" <
> adam.carb...@bottomline.com>
> *Cc: *"u...@ignite.apache.org"
> *Subject: *Re: [DISCUSSION] Renaming Ignite's product category
>
>
>
> Adam,
>
>
&
"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
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
To: dev , "Carbone, Adam"
Cc: "u...@ignite.apache.org"
Subject: Re: [DISCUSSION] Renaming Ignite's product category
Adam,
You defined GigaSpaces as a true in-memory computing platform. What is the true
platform for you?
-
Denis
On Fri, Sep 18, 2020 at 7:02 AM Carbone, Ad
Adam,
You defined GigaSpaces as a true in-memory computing platform. What is the
true platform for you?
-
Denis
On Fri, Sep 18, 2020 at 7:02 AM Carbone, Adam
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
+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
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
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
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
Hello!
The word "traditional" here is not about the technology age. It's about
using buffer pool like in traditional databases (PG, Oracle, etc).
--
Roman Kondakov
On 17.09.2020 17:09, Ilya Kasnacheev wrote:
Hello!
Can you please clarify which databases you refer to when you say
Hello!
Can you please clarify which databases you refer to when you say
"traditional distributed databases"?
I didn't consider it to be a mature enough field to have tradition.
Regards,
--
Ilya Kasnacheev
чт, 17 сент. 2020 г. в 13:44, Roman Kondakov :
> I would not say that Ignite is an
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
I would not say that Ignite is an in-memory database in a general sense
of this term. Ignite uses disk-oriented buffer pools (aka page memory)
under the hood, which makes similar to traditional distributed
databases. See abstract and intro in [1] for detailed explanation of the
differences
Agree with Val, even experienced developers have a hard time understanding
what "in-memory computing platform" really does.
"distributed memory-first database" is right on point.
On Thu, Sep 17, 2020 at 8:30 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> My vote is for the
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
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
20 matches
Mail list logo
