couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jedediah Smith <jeded...@silencegreys.com>
Subject Re: 1.0.0 wishlist/roadmap
Date Wed, 03 Dec 2008 10:47:50 GMT


Damien Katz wrote:
> - Restrict database read access -
> 
> Right now any user can read any database, we need to be able to restrict 
> that at least on a whole database level.
 >
 > - Built-in authentication module(s) -
 >
 > The ability to host a CouchDB database used for HTTP authentication
 > schemes. If storing passwords, they would need to be stored encrypted,
 > decrypted on demand by the authentication process.

I wouldn't launch with anything less than extensible, per-doc read/write 
control as this is vital for pure couch web services and AJAX apps.

I've been brainstorming this and it's tricky, especially with views. 
I'll writeup some ideas when I have time.


> - Revision stemming: It should be possible to limit the number of 
> revisions tracked -
> 
> By default each document edit produces a revision id that is tracked 
> indefinitely. This guarantees conflicts versus subsequent edits can 
> always be distinguished in ad-hoc replication, however the forever 
> growing list of revisions isn't always desirable. THis can be addressed 
> by limiting the number tracked and purging the oldest revisions. The 
> downside is that if the revision tracking limited is N, then anyone who 
> hasn't replicated a document since its last N edits will see a spurious 
> edit conflict.

/db/_purge_revisions?before_seq=12345


> The _rev will be the PREVIOUS revision ID/hash the edit is 
> based on, or blank if a new edit. Then the _rev is replaced with the new 
> hash value.

This is quite clever

Mime
View raw message