MBOX-Line: From witold.krecicki at firma.o2.pl  Mon Jun 14 14:09:56 2010
To: imap-protocol@u.washington.edu
From: Witold =?utf-8?q?Kr=C4=99cicki?= <witold.krecicki@firma.o2.pl>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <alpine.OSX.2.00.1006141344000.662@hsinghsing.panda.com>
References: <915336234.3135.1276547291546.JavaMail.root@dogfood.zimbra.com>
	<alpine.OSX.2.00.1006141344000.662@hsinghsing.panda.com>
Message-ID: <201006142309.56688.witold.krecicki@firma.o2.pl>

On Monday 14 of June 2010 22:54:14 Mark Crispin wrote:
> 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.
A database that is ran on a cluster has the HUGE advantage of capability of 
surviving really large loads and severe system failures. And a small 
disadvantage of no real possibility of single-instantion-store. Think beyond 
1000-user servers.

-- 
Witold Kr?cicki

Grupa o2 Sp??ka z o.o., ul. Jutrzenki 177, 02-231 Warszawa,
KRS 0000140518, S?d Rejonowy dla m.st. Warszawy, 
Kapita? zak?adowy 377.298,00 z?., NIP 521-31-11-513

