[Dovecot] Trash expire plugin

[Timo Sirainen]

On Thu, 2006-06-08 at 11:45 -0500, Les Mikesell wrote:
> On Thu, 2006-06-08 at 18:32 +0300, Timo Sirainen wrote:
> > On Thu, 2006-06-08 at 17:33 +0300, Timo Sirainen wrote:
> > > 3) Add a new field to index file which contains the date when the
> > > message was copied. This could be done only for those Trash/Spam boxes
> > > so they don't waste space for other mailboxes. The problem with this is
> > > that it won't work if there are no index files. To overcome that problem
> > > the time could be stored in yet another place, such as maildir filename
> > > and some new mbox header. I don't see supporting those as worth the
> > > trouble though, so the fallback could be either the date index file is
> > > created or the messages' INTERNALDATE.
> > 
> > Actually for maildir the time is in file's ctime, so that would be a
> > good fallback. For dbox I could add a new field if people think it is
> > useful (might be useful for other purposes also?).
> 
> Ctime will change if you rename the file - don't some operations
> do that?

Yes. But if you're doing operations (flag changes mostly) for the mail,
I think it might be even good that the timer gets reset.

> > mbox users are out of luck though. For them the fallback could be the
> > current date, so as long as the indexes usually stay for longer than the
> > expire days, this works well enough.
> 
> The recent sql discussion made me have an off-the-wall idea... Have you
> considered adapting the cyrus file structure as a back-end option
> for dovecot?

Well, the Cyrus format's index files are somewhat similar to Dovecot's
index files. There's no point in duplicating those, so either with Cyrus
backend the Dovecot indexes wouldn't be used or the Cyrus indexes
wouldn't be used.

Not using Cyrus indexes could be done in two ways: 1) Keep them updated,
just don't really use them. Not exactly optimal since disk I/O is still
wasted on them. 2) Don't keep them updated, which breaks all other Cyrus
backend users.

Not using Dovecot indexes would be possible, but to make it work fast it
would require rewriting a lot of Dovecot code to work differently.
Really not worth the trouble.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20060608/9bf12bf1/attachment.pgp