MBOX-Line: From mrc+imap at panda.com  Mon Jun 14 13:54:14 2010
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <915336234.3135.1276547291546.JavaMail.root@dogfood.zimbra.com>
References: <915336234.3135.1276547291546.JavaMail.root@dogfood.zimbra.com>
Message-ID: <alpine.OSX.2.00.1006141344000.662@hsinghsing.panda.com>

On Mon, 14 Jun 2010, Dan Karp wrote:
> In addition, you could posit a store where the searchable message
> content (for SEARCH BODY, etc.) is shared among all copies of a
> message.  In such a store, once a COPY was performed you'd end up
> in a more expensive ref-counting mode for subsequent deletes of
> copied messages, a mode avoided in the absence of a COPY op.

That assumes that you care how many references there are to the message
content, presumably for space reclamation when the last user is dropped.
That isn't necessarily a valid assumption (e.g., not in CAstor).

In effect, a database which requires separate instances of a message for
each consumer of the message has all the disadvantages of both flat file
and a filesystem directory, but none of the advantages of either.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

