couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <>
Subject Re: Unique instance IDs?
Date Thu, 15 Dec 2011 02:10:17 GMT
On Wed, Dec 14, 2011 at 04:13:41PM -0800, Randall Leeds wrote:
> I might argue that these bits at the end are link and network layer
> issues that we don't care about.

On the contrary - until there is a solution in the mainline to deal with
NATs and firewalls, you cannot assume that a CouchDB instance can be
seen publicly. A very common use case (for the application I've been
working on) is for a desktop machine, behind a NAT, to have continuous
2-way replication with a public server. Imagine 30 or so machines
connected to such a central server. 31 databases, 62 ongoing
replications, but only one them has a valid URL. Each desktop will have
to pull from and push to the central server; the central server on its
*own* cannot access the machines behind the firewalls.

This is not so unusual a case, is it?

> pulling from or pushing to the device. In this case, the db on the
> mobile device can be identified by a bare database name without any
> URL at all. Examples: Pull http://remotecouch/mydb -> mydb; Push mydb
> -> http://remotercouch/mydb. The replicator works like this today.

See above - the same approach (the exact opposite of what you've
suggested) is the most workable solution *today*.

> The CouchDB community is being very radical by suggesting that we
> might _serve_ content or address content stored on a mobile device.

Yes! And further more solving how to serve data from behind a NAT or
firewall is equally challenging - but doable.

> Given the commitment CouchDB has made to HTTP so far, I hesitate to
> say that the solution to this problem is to subvert URLs.

I'm not saying that's the solution. I'm saying that URLs cannot
necessarily identify all participants in a replication scenario
reliably, especially given RFC 1918 space, variable host names, mobile
platforms and NAT.

> Again, this is getting away from the transitive checkpoint problem,
> which may turn out to obviate the need for identification of databases
> in the first place. Or, as I put it earlier, to focus the problem on
> "what is in this database" rather than "what database this is".

+100 on solving things this way. :)


View raw message