Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of b.candler@pobox.com designates
 207.106.133.19 as permitted sender)
Date: Fri, 13 Feb 2009 06:01:59 +0000
From: Brian Candler <B.Candler@pobox.com>
To: user@couchdb.apache.org
Subject: Re: Couch as a mail store?
Message-ID: <20090213060159.GB6049@uk.tiscali.com>
References: <fad9d4840902120613m32a79877gf0503bda1f1fc27d@mail.gmail.com>
 <20090212161918.GB24119@uk.tiscali.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E27245D3-DD9A-453F-AA78-013A0F1CCC5F@apache.org>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

> > Of course, SMTP clients don't mind a small delay before they get  
> > their 250
> > OK at the end of the message; you can therefore write a number of  
> > batches
> > and do an fsync() every second or so, as long as you remember not to  
> > send
> > the acknowledgement back to each client until *after* the fsync has
> > completed.
> 
> CouchDB does the fsync()-a-second currently.

But I don't think this is currently exposed to the client. You'd need a
"wait until next fsync has completed" request, to let you know that it's
safe to send back a 250 OK to the client.

A couple of other thoughts:

(4) E-mail systems create and delete millions of documents per day. Is it
true that couchdb keeps a small amount of data around indefinitely for every
deleted document, for replication purposes? If so this would keep growing.
(And whilst I've seen discussion about pruning old _revs, I've not seen
discussion of pruning deleted documents)

(5) I believe the IMAP protocol makes some RDBMS-type demands on a
mailstore, in particular the allocation of contiguous sequence numbers to
each message. Some careful thought would be needed on how to do this, as it
may make full replication difficult - or at least increase the likelihood of
replication conflicts, so would benefit from the planned feature of being
able to specify custom conflict-resolution logic.

(6) Another planned/not-yet-complete feature which would be very useful for
a mail store is the document-level access control logic, which could for
example be used for IMAP ACLs and shared mailboxes.

Regards,

Brian.