Benoit, Thanks for mentioning the "links" item, that should definitely be in the list. I'd be curious to know what kind if usage the Basho folks have seen with that one.
I think it's a good feature but I also think it kind of runs against the grain architecturally in couchdb. Documents now are completely independent of one another which is simple. This forces use cases that need "links" to do so in the application layer. There are many reasons I think of that folks would want this, building trees, graphs, SQL-like queries, navigation, etc. so I think it's a nice feature to add, *but* I would do so in a way that doesn't change the independence of documents, .ie. make it orthogonal, a plugin to core. Bob On Apr 15, 2012, at 6:17 AM, Benoit Chesneau wrote: > On Sun, Apr 15, 2012 at 12:02 PM, Robert Newson <[email protected]> wrote: >> He's what I have so far: https://gist.github.com/2387973 >> >> I think it's pretty close. Only the User-Facing section should be in >> the next vote. >> >> B. >> > Most is OK for me. A couple of remarks on user facing though: > > 1.3 : _rev renaming should be placed in another part, and maybe a > developper facing thing . Also other way to embrace it is proposing an > _history member. > > 3. we shouldn't talk about a specific tech. As far as I rememebr we > only talk on a distributed PKI wich openid isn't. OpenID is fine but > maybe we can put the choice of supported implementations for a next > vote? > > 4. maybe can be summarized as "metadata won't be exposed in the Json > Document" ? Or at least the raw document won't be edited by couch. > Some on irc for example was proposing for example to have {"_id": ..., > "_raw": ...} > > links/nested doc feature is missing . > > > I will do another round on dev facing features later. > > - benoît
