On Wed, Dec 14, 2011 at 14:52, Joan Touzet <[email protected]> wrote: > -1 on using URI/URLs, for the simple fact that mobile and desktop > devices often don't have a stable hostname and/or IP address. This is a > huge area where CouchDB is used, increasingly so, and attempting to tie > a DB UUID to something inherently variable on the platform is doomed to > fail. > > Renaming my PC or phone, getting a new DHCP address, connecting to a > different network or changing the MAC address of my NIC should not > invalidate my DBs, their "UUIDs", or cause unreasonable problems for > replication. > > -Joan
I might argue that these bits at the end are link and network layer issues that we don't care about. As far as the Web is concerned, the URL is the address and it's more than just convenience and readability that separates that from an IP address. URLs are foundational to resource identification on the Web, and I'm really hesitant to "work around" that (nevertheless I've dreaming up and reading all kinds of ways to do just this these days, and it's pretty hard). I definitely don't mean to condescendingly suggest you don't know this already; I'm just restating the basic facts. Take, for example, the mobile use case. Most people, I'd submit, want to push from and pull data to a mobile device. Given that the device doesn't have a stable address (neither in IP nor URL space), most would punt on the problem of serving from the mobile device, i.e. 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. I think it's generally accepted that URLs don't point at the same device all the time. In practice, obviously, they very frequently "point at many devices" in that reverse proxies are used all over the Web for load balancing. I might say it's out of scope for CouchDB to worry about tying a stable URL to a mobile device. For the ops person in the datacenter the story right now is clear: if you want to copy your database, you should probably also copy the hostname over to the new box or replication starts over. The CouchDB community is being very radical by suggesting that we might _serve_ content or address content stored on a mobile device. Given the commitment CouchDB has made to HTTP so far, I hesitate to say that the solution to this problem is to subvert URLs. 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". -Randall
