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
