38 lines
1.8 KiB
Plaintext
38 lines
1.8 KiB
Plaintext
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
|
|
|