Hello!

Thank you, Garren for your inputs.

CouchDB would be a pretty poor fit for running on a small embedded device.

CouchDB as it is now will be a poor fit for embedded systems/IoTs. There is no denying this fact.

I know of people that use PouchDB to
run on the embedded device and then replicate the data to a CouchDB server.
That is a pretty standard way of doing it and should support most IoT
situations
Although Node-RED is creating some buzz lately, JavaScript is not a good fit for embedded systems programming. Erlang/Elixir are much better suited because of friendly fault tolerance.

All you need to do is store that data locally until
you have internet access and then send the data to a CouchDB cluster for
processing
For IoTs we will have to take other factors into account like in the near future there can be billions of IoT devices attempting to send data from remote locations or data transmission might stop due to some unforeseen circumstances or device runs out of power and we have to wait for the Sun to come back, etc.

The future Cluster Of Unreliable Commodity Hardware requires us to build while keeping various fault causing scenarios in our minds. Embedded system developers already have their hands full with all the systems programming they have to do to optimize their hardware resources. For these developers, IoT has added a new challenge of storing and sending the data. This technological challenge requires them to understand various internet protocols, particularly HTTP and MQTT. To add to their woes they have to solve aforementioned challenges. All this adds up as a technical burden.

Most the time the data on an embedded device is metrics
of some sort e.g speed, temperature or something similar. You don't need
replication for that.

That is true. IoTs rarely work with nested data. CouchDB supports Filter Replication, some re-imagination will make it suitable for the purpose of IoT.

On 08/07/19 5:51 PM, Garren Smith wrote:

CouchDB would be a pretty poor fit for running on a small embedded device.
But CouchDB's API is a great standard. I know of people that use PouchDB to
run on the embedded device and then replicate the data to a CouchDB server.
That is a pretty standard way of doing it and should support most IoT
situations. I guess in the future it would be nice to have a small
embeddable CouchDB like server that isn't written in Erlang or javascript
that could then replicate or communicate to a CouchDB server.

The other thing to look at is often replicating IoT data to a server is
overly complicated. Most the time the data on an embedded device is metrics
of some sort e.g speed, temperature or something similar. You don't need
replication for that. All you need to do is store that data locally until
you have internet access and then send the data to a CouchDB cluster for
processing.

On Mon, Jul 8, 2019 at 12:44 PM Chintan Mishra <chin...@rebhu.com> wrote:

Hello,
There is no other database that does CouchDB-Style replication, that’s a
very clear and long-standing unique feature. Our particular combination of
JSON/HTTP/REST API is also pretty compelling. I’m sure we can make a better
job of explaining all that to people and I’m happy to review PRs for our
website, docs, and drafts for our blog and discuss details on the marketing@
list.
The ease of replication, specifically multi-master, is unmatched when
compared to many other NoSQL DBs. But now that most NoSQL DBs have
adopted JSON/HTTP/REST API we cannot count it as a distinguishing factor.

Market changes with time and consumer demands. We are at Nokia stage of
multiple industries mentioned earlier. They will achieve their
iOS/Android stage. The closer we align ourselves to the emerging
technologies the easier it will be for us to stay relevant in the
upcoming changes. I still stand by my inclination towards making CouchDB
relevant from Web to IoT.
If that was true, the ASF board would shut down the project, as it is
one of the things we have to provide a report on on a quarterly basis. All
future direction of the project is discussed here and for my part, I
understand where the project is going, even if I’m personally not involved
in all the initiatives.
If anyone’s specific vision isn’t included in our roadmap, we can talk
about that, but know that we have to be very careful about allocating
project resources towards the things we know we can ship vs. the ones that
are a lot of work for not a lot of gain that subsequently nobody signs up
to actually do.

CouchDB is a very powerful project even with an improperly communicated
direction. And it solves 'something' better than any other DB. And pin
pointing this 'something' is very challenging. This 'something' is the
reason why people who use it fall in love with it. As a user this
'something' and the future direction both are unclear.

Can you share a link to the mailing list where we can read about these
updates? This will help us improve website, marketing material, and more.

On 08/07/19 3:33 PM, Jan Lehnardt wrote:
Hi,

While I agree that there are many things that can be improved with
CouchDB (we have an issue tracker full of them e.g.), I want to address
these two assertions:
lack of unique competitive advantage,
There is no other database that does CouchDB-Style replication, that’s a
very clear and long-standing unique feature. Our particular combination of
JSON/HTTP/REST API is also pretty compelling. I’m sure we can make a better
job of explaining all that to people and I’m happy to review PRs for our
website, docs, and drafts for our blog and discuss details on the marketing@
list.
and unclear future direction
If that was true, the ASF board would shut down the project, as it is
one of the things we have to provide a report on on a quarterly basis. All
future direction of the project is discussed here and for my part, I
understand where the project is going, even if I’m personally not involved
in all the initiatives.
If anyone’s specific vision isn’t included in our roadmap, we can talk
about that, but know that we have to be very careful about allocating
project resources towards the things we know we can ship vs. the ones that
are a lot of work for not a lot of gain that subsequently nobody signs up
to actually do.
Best
Jan
—


On 8. Jul 2019, at 11:16, Chintan Mishra <chin...@rebhu.com> wrote:

Hello,


On 08/07/19 1:32 PM, Robert Samuel Newson wrote:
Hi,

I understand what marketing is, but I also understand how this project
is organised. The dev@ mailing list is where project direction and
development is discussed, and where all decisions must be made, which is
why I asked that the conversation moved here. Not many are signed up to the
marketing mailing list.
I hear and share your concerns about “IBM employees” (and I am one,
but was not one for the majority of my involvement with CouchDB, like all
the others that are now IBM employees). We have bylaws and a code of
conduct and a PMC with many non-IBM employees. It should go without saying
that those committers and PMC members who are also IBM employees are mature
adults capable of working in open source with integrity. Were that ever to
stop being the case, there would be consequences.
The conversations about future direction (foundationdb et al) happened
here on this mailing list and everyone was welcome to raise the concerns
you did. Those conversations, and RFC’s, will continue to happen here.
Ultimately, the project moves forward in the direction that active
contributions take it under the watchful eye of the PMC.
Chitan’s thoughts on IoT are very welcome, which is why I wanted the
conversation here, where project ideas can be discussed with everyone
interested in them. I also hope my reply that pointed out why CouchDB is
not yet ideal for IoT was constructive. It is not just a question of
marketing CouchDB as it is today, it should inform CouchDB project
direction.
B.
either
Johs raised some genuine concerns.We all are raising our voice/concern
because we believe in CouchDB. I have failed to see the masses love it as I
do. I have been using CouchDB for around 1.5 years, probably lot lesser
than most other subscribers here. In this time, I quickly realized that
CouchDB is sitting on an underutilized goldmine. I share the concerns
raised by Johs regarding unclear market, lack of unique competitive
advantage, and unclear future direction while keeping existing user base.
These are all the things that confused me in 2016 while deciding a suitable
NoSQL Document DB for my use case. After trying 3 NoSQL Document DB, I was
lucky to finally choose CouchDB.
Robert, I understand bylaws and other rules in place are for us to keep
this civil, maintainable, and organized.
We are living in an era where products are consumer centric and some
discussions will not have a clear boundary. The discussions will revolve
around tech and market. Most of the time we will end up discussing both. We
will talk about arising the customer/developer/industry needs and how we
can build CouchDB which helps them excel. I see why IoT stuff cannot be
done right now. And I wouldn't recommend as it is today.
CouchDB led the way by realizing that future infrastructure will hugely
rely on HTTP and built the first DB with a HTTP API for accessing and
manipulating data. Newer advancements in technologies will always demand us
to rethink our market position. We need to discuss that few years from now
when IoTs, spatial/location-based services(drones, self-driving vehicles),
analytic, etc. are the new normal then who will still use CouchDB despite
other products in the market. Once we have figured who we want to build
for, we all can start focusing on building it.
PS: If you have 180 seconds to kill: https://youtu.be/DFeeNLElBgU

Regards
Chintan
On 8 Jul 2019, at 07:08, Johs Ensby <j...@b2w.com> wrote:

I find Chitan's reflections very interesting,
even if the current direction for CouchDB points in a different
direction.
The problem is that CouchDBs future is difficult to understand, as
marketing discussions are discouraged.
This is a very good example of how it is done:

Briefly, this mailing list is for marketing only. If you wish to
discuss project direction, post to the dev mailing list instead.
This reveils a total lack of basic understanding of what marketing is.
Just as a hint: Marketing is not the same as promotion. Marketing is
a concept and a dicipline that arose in the 1960's as two previous concepts
failed to capture the challenge of bringing products to the market.
The "producion concept" worked as long as the market was underserved
and you could focus on production, the market would swallow all available
products (early days of mass production and hitech dev)
The "sales concept" was characterized by strategies for pushing the
products to market.
The "marketing concept" turned the whole thing around and focused on
identifying needs and wants in the market to which products could be
developed in order to create value for the user/customer.
A definition of marketing used by my professor at Harvard Business
School was: Marketing is to create value and retain a fair share of that
value.
The notion that writing blog posts is marketing, unfortunately brings
us to the pre-1960's thinking of how to bring a product to market.
I am increasingly worried about the CouchDB project being dominated
by IBM employees, and that new versions will require major workovers of
CouchDB without concern as to:
- what market is targeted
- what competitive position in this market is being targeted
- how to build on the existing user base for future success

The latter point is crucial in order to make any technology adoption
work, this is based on another theory that has been known since the 60's
("The diffusion of innovation" by Everett Rogers), popularised and brought
to hitech in the early 90's by Jeff More's "Crossing the chasm".
Chitans reflections on how to serve markets in need of new solutions
is the kind of marketing discussion that CouchDB would benefit greatly from
inviting.
johs

On 7 Jul 2019, at 19:55, Robert Samuel Newson <rnew...@apache.org>
wrote:
Hi,

The main (current) difficulties in running CouchDB on embedded
devices is running erlang there coupled with our clustering stack. To scale
everything down to fit within the typical constraints of an embedded device
requires effort, I don’t think couch “just works” there.
The future release that replaces the clustering technology with
FoundationDB is what I refer to by “getting harder in the future”. While
fdb does scale down well, it might still need porting to platforms it’s not
currently supported on.
As for suitability for IoT, couch is certainly used in that field,
but care must be taken, especially around the core notion that couch
retains information about a deleted document forever. This small amount of
data can build up, and you need to plan for it.
B.


On 7 Jul 2019, at 08:02, Chintan Mishra <chin...@rebhu.com> wrote:

Dear team,

Quoting myself from <market...@couchdb.apache.org>

----

3. A *way forward for CouchDB is focusing on what it is best*at
viz.,
being a database for _*C*__luster __*O*__f __*U*__nreliable
__*C*__ommodity __*H*__ardware_. Being deploy-able at edge devices.
Focusing on this will invite people building for IoTs towards
CouchDB. And this will drive a whole new set of users/customers
towards CouchDB and IBM's Cloudant project. We already use
Cloudant's sync-android and CDTDatastore in our startup's(Rebhu
Computing) product.

----

I would like to draw attention to this point. I firmly believe that
CouchDB can benefit by targeting IoT device developers. IoT
developers don't want to worry about sending data from edge devices
to server for processing. CouchDB already has battle-tested
replication strategy. Extending this for IoT devs will drive the
next age developers. CouchDB is already made for unreliable systems
and what is more unreliable than an IoT lying in the sea connected
with worldwide GSM/CDMA (2G) network.

Quoting Robert Newson's <rnew...@apache.org> response

It’s a good point but not for the marketing list unless you are
talking just about producing blog posts or other materials to promote
couchdb for that market?
I think to make couchdb more useful for iot would require some
development work. Running couchdb on embedded devices is already a
challenge and it’s only going to get harder in future. As a server side
hub, the retention of a small amount of data after document deletion
presents further problems.
Briefly, this mailing list is for marketing only. If you wish to
discuss project direction, post to the dev mailing list instead.
Thanks.

@Robert_Newson can you shed some light on the issues that arise
while deploying CouchDB on embedded devices? Also, what is going to get
harder in the future?
--
Chintan Mishra
Founder and CEO
Rebhu Computing

Reply via email to