The CouchDB project has been getting a lot of talk lately, all over the blogosphere and in particular in Python circles, who like JSON and REST and are excited at the new move to them from XML. I really liked what I saw. I also knew I could have liked it a lot more.
You know something interesting is happening when someone with my anti-XML track record says the following: XML should not have been dropped from CouchDB.
I can clarify and reaffirm that I am not crazy by saying that this does not mean JSON should not have been added, but that it should not have replaced anything. In other words, both are fine. While we're at it, why does it matter what format the "document" is in? Be it an XML document, a JSON serialization, or a photo, anything could benefit from the basic architecture of CouchDB.
Looking into the details, I'm disappointed that the distribution model is just smarter replication. Something like this really should be able to do sharding out of the box, with its really unique identifiers and revisioned nature.
Can CouchDB satisfy my requriements or do I need to write SofaCouchDB?
You know something interesting is happening when someone with my anti-XML track record says the following: XML should not have been dropped from CouchDB.
I can clarify and reaffirm that I am not crazy by saying that this does not mean JSON should not have been added, but that it should not have replaced anything. In other words, both are fine. While we're at it, why does it matter what format the "document" is in? Be it an XML document, a JSON serialization, or a photo, anything could benefit from the basic architecture of CouchDB.
Looking into the details, I'm disappointed that the distribution model is just smarter replication. Something like this really should be able to do sharding out of the box, with its really unique identifiers and revisioned nature.
Can CouchDB satisfy my requriements or do I need to write SofaCouchDB?
Comments