Hi, I've joined this mailing-list, because i wanted to reply to this discussion specifically. I was hoping you could clear a number of things up for me.
1. Why make compacting the default? Isn't more likely that in this day & age, most will prefer revisions for all data? 2. Compacting seems like very specific behavior, wouldn't a built-in cron-like system be much more generic? It could allow for all kinds of background proccessing, like replication, fulltext-search using javascript, compacting, searching-for-dead-urls, etc. 3. Is support for some sort of reduce behavior, as part of the views, planned and ifso, what can we expect? 4. What is the default conflict behavor? Most recent version wins? 5. Is it possible to merge on conflicts, or ifnot, how could attachments possible properly model revisions. Wouldn't we loose a whole revision tree? 6. Without merging, we need to store revisions in seperate documents, thereby prohibiting usefull doc-is for documents under revision. 7. What added benefit do manual revisisons have when we can just store extra revision data to each document anyway? I'm quite sure my understanding of CouchDB can be lacking. But to me it seems like garantueed revisisions are the killer feature. The alternative of a cron-like system, could work much like the view-documents. These documents could contain a source url (possibly local), a schedule-parameter and a function that maps a document to an array of documents that is treated as a batch-put. This way we could easily setup replication, but also all kinds of delayed and/or scheduled proccessing of data. Likewise, being able to define a conflict function that could merge data or decide who wins, seems like a much better alternative to the 'atomic' batch-put-operations, that break down when distributed. (thereby no longer garantueeing the scalability; another killer-feature). Greetings, Ralf Nieuwenhuijsen
