http://dovecot.org/test/
Keywords are finally stored in maildir filenames and listed in
"dovecot-keywords" file. It should be possible to just rename
0.99.x's
.customflags file to dovecot-keywords (but it can't be renamed back
after modification).
Also fixed another uid/sequence mixup bug with setting keywords in
general (in mbox too).
Fixed SHA1 checksum generation with big-endian machines (used only in
passwords).
I think I'll forget about the master/config rewrite for a while and
leave it for Dovecot v2.0. That would mean the next release will be
called 1.0-alpha1. After that there should be only bugfixes and some
smaller features and optimizations left.
I looked through my TODO and found the following missing features /
optimizations that pretty much have to be done before v1.0. Anything
important missing?
- keywords:
- add some limits to how many there can be
- send FLAGS/PERMANENTFLAGS untagged replies when they change
(required by IMAP RFC)
- remove unused keywords from keyword list? (only when adding new
ones)
- mail cache file
- cache _all_ headers that are marked to be cached when headers are
being parsed, not just the ones client is requesting at that
time.
- compression should drop fields with last_used <
(latest_mail_index_date - month)
- when parsing mbox or saving message, parse the mail through
index-mail
so things gets saved into cache immediately
- mbox
- when we're updating flags with lazy writing, we're still parsing
the
mbox, just not writing to it!
- always add empty line after mail.
- make the parser require it too? syncing should make sure
there
always exists two LFs at end of file. raw-mbox-stream should
make sure the last message ends with LF even if it doesn't exist
in the file
- COPY doesn't work to same mailbox (lock assert crash)
- keep mbox lock for two extra seconds after sync to make sure we
notice changes made by other mbox writer software
- maildir
- hardlink copying doesn't update indexes (does it even work?)
- deliver needs quota integration somehow so it returns out-of-quota
failure as fatal instead of temporary
Probably after v1.0:
- Full NFS support
- Try to handle out-of-quota/disk space situations well
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20050701/25f9b620/attachment-0001.bin>
Timo Sirainen wrote:> > I think I'll forget about the master/config rewrite for a while and > leave it for Dovecot v2.0. That would mean the next release will be > called 1.0-alpha1. After that there should be only bugfixes and some > smaller features and optimizations left.Sounds reasonable. Mind you, it feels scary migrating our 20,000 users to an "alpha" product! (This week I managed to switch ~120 University Admin staff, who are some of our heaviest users, to use Dovecot 1.0-stable with mbox, instead of UW-IMAP, without them noticing! So far, it seems that Dovecot is reading one third of the disk blocks and using half the CPU than UW-IMAP, for them.)> > I looked through my TODO and found the following missing features / > optimizations that pretty much have to be done before v1.0. Anything > important missing? ><snip>> > - mail cache file > - cache _all_ headers that are marked to be cached when headers are > being parsed, not just the ones client is requesting at that time. > - compression should drop fields with last_used < > (latest_mail_index_date - month) > - when parsing mbox or saving message, parse the mail through > index-mail > so things gets saved into cache immediatelyI'm still not convinced the cache file is shrinking properly for me. Do entries get expired after a set time at the moment (in 1.0-stable)? Anyway, it would be nice to be able to configure the lifetime (e.g. may be less than a month). I've noticed that if you've got a lot of messages - and I'm being deliberately naughty with my INBOX ;) - doing a full search will lead to a big cache file, even though the user is less likely to read the oldest messages. Best Wishes, Chris -- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin at reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
On Thursday 30 June 2005 23:29, Timo Sirainen wrote:> http://dovecot.org/test/ > > Keywords are finally stored in maildir filenames and listed in > "dovecot-keywords" file. It should be possible to just rename > 0.99.x's .customflags file to dovecot-keywords (but it can't be > renamed back after modification). > > Also fixed another uid/sequence mixup bug with setting keywords in > general (in mbox too). > > Fixed SHA1 checksum generation with big-endian machines (used only in > passwords). > > I think I'll forget about the master/config rewrite for a while and > leave it for Dovecot v2.0. That would mean the next release will be > called 1.0-alpha1. After that there should be only bugfixes and some > smaller features and optimizations left.A 1.0 release would be nice :-)> I looked through my TODO and found the following missing features / > optimizations that pretty much have to be done before v1.0. Anything > important missing? > > - keywords: > - add some limits to how many there can be > - send FLAGS/PERMANENTFLAGS untagged replies when they change > (required by IMAP RFC) > - remove unused keywords from keyword list? (only when adding > new ones) > > - mail cache file > - cache _all_ headers that are marked to be cached when headers > are being parsed, not just the ones client is requesting at that > time. > - compression should drop fields with last_used < > (latest_mail_index_date - month) > - when parsing mbox or saving message, parse the mail through > index-mail > so things gets saved into cache immediately > > - mbox > - when we're updating flags with lazy writing, we're still > parsing the > mbox, just not writing to it! > - always add empty line after mail. > - make the parser require it too? syncing should make sure > there > always exists two LFs at end of file. raw-mbox-stream should > make sure the last message ends with LF even if it doesn't exist > in the file > - COPY doesn't work to same mailbox (lock assert crash) > - keep mbox lock for two extra seconds after sync to make sure > we notice changes made by other mbox writer software > > - maildir > - hardlink copying doesn't update indexes (does it even work?) > > - deliver needs quota integration somehow so it returns > out-of-quota failure as fatal instead of temporary > > Probably after v1.0: > - Full NFS support > - Try to handle out-of-quota/disk space situations wellAny chance of kqueue support for us BSD users? I think the diff I have could probably be the basis of support for it. Thanks, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. -------------- next part -------------- A non-text attachment was scrubbed... Name: ioloop-kevent.c.gz Type: application/x-gzip Size: 1840 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20050701/e44e9aba/attachment-0001.gz>
Le 1 juil. 05 ? 00:29, Timo Sirainen a ?crit :> - maildir > - hardlink copying doesn't update indexes (does it even work?)This is a bit scary, as I had this enabled (under 74) and I did not notice anything bad. Could you elaborae a little? Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://dovecot.org/pipermail/dovecot/attachments/20050701/d2e98325/attachment-0003.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Ceci est une signature ?lectronique PGP URL: <http://dovecot.org/pipermail/dovecot/attachments/20050701/d2e98325/attachment-0001.bin>
On Fri, 1 Jul 2005, Timo Sirainen wrote: What's the status of Dovecot-LDA? Should/can it become part of the Dovecot v1.0 package? Bye, -- Steffen Kaiser
> Probably after v1.0: > - Full NFS supportWhat does this mean? What might happen now, while NFS isn't fully supported?> - Try to handle out-of-quota/disk space situations wellHappily, I guess we've got enough space for now.