31 lines
1.4 KiB
Plaintext
31 lines
1.4 KiB
Plaintext
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.
|
|
|