I think I won't do any actual releases until it's mostly feature complete. Then maybe v1.1.alpha1 or v1.1.beta1. So if you want to test it before then, use CVS or the nightly snapshots. I'm planning on keeping v1.1 almost completely compatible with v1.0. There could be some minor configuration file changes, but for most people v1.0's dovecot.conf should work with v1.1. I want to update index file handling to use less locks and update dovecot.index file less often. The file formats would still stay backwards compatible with v1.0. After this I'm hoping to get index files working well with NFS even with attribute cache enabled. Dovecot v2.0 then brings incompatible index files and more or less rewritten configuration file handling. It could still support old config file format and settings, but the default will be somewhat different. I'm hoping to release the first alphas/betas in 2-3 months, with v1.1.0 maybe even as early as next summer. The good thing here is that index file code hasn't changed much since v1.0, so it should be stable. The bad thing is that I've added a couple of completely new indexes. I'm also quite busy for the next month, but I'm not sure how much it affects my coding. :) The largest already implemented new features are: + Added support for IMAP UIDPLUS extension + IMAP SORT: Sort keys are indexed, which makes SORT commands faster. + IMAP THREAD: Threads are indexed into a dovecot.index.thread file. It can usually be updated incrementally, so this makes THREAD fast. + Added Dovecot-specific X-REFERENCES2 threading algorithm. It's similar to REFERENCES, but it doesn't do base subject merging and it sorts the threads by their newest message. + When saving messages, update cache file immediately with the data that we expect client to fetch later. Maildir-only currently. + Mailbox list indexes. Mailbox metadata is stored there, so STATUS commands can return synchronized mailboxes' metadata simply by reading a single mailbox list index file. - FIXME: Currently works only with Maildir++ layout. + Expire plugin can be used to keep track of oldest messages in specific mailboxes. A nightly run can then quickly expunge old messages from the mailboxes that have them. The tracking is done using lib-dict, so you can use either Berkeley DB or SQL database. + Namespaces are supported everywhere now. - FIXME: except by convert plugin + Full text search indexing support with Lucene and Squat backends. + OTP and S/KEY authentication mechanisms (by Andrey Panin). + mbox and Maildir works with both Maildir++ and FS layouts. You can change these by appending :LAYOUT=maildir++ or :LAYOUT=fs to mail_location. Features that I'm planning on implementing: - Fully supported shared mailboxes and IMAP ACL extension - Replace Squat FTS indexes with my new design - Case-insensitive searches with non-ASCII text as well - Maybe add support for all kinds of IMAP extensions that can be easily supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe even URLAUTH if I can figure out how it should work. If a feature can be implemented completely as a plugin, it could still come in v1.1.beta stage, because it won't destabilize the rest of the Dovecot anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070417/6fcbfc66/attachment.bin>
Timo Sirainen wrote:> > Features that I'm planning on implementing: > > - Fully supported shared mailboxes and IMAP ACL extension > - Replace Squat FTS indexes with my new design > - Case-insensitive searches with non-ASCII text as well > - Maybe add support for all kinds of IMAP extensions that can be easily > supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe > even URLAUTH if I can figure out how it should work. > > If a feature can be implemented completely as a plugin, it could still > come in v1.1.beta stage, because it won't destabilize the rest of the > Dovecot anyway. >In my testing of using sql dictionary for quota, it appears pretty buggy. Are you aware of such problems? Either way, would you consider reliable dictionary quota support a target for 1.1? I did find that it seemed to blow maildir++ away in terms of performance. We have a few really large maildirs that basically choke when quota is enabled using maildir++ (200,000+ messages). On top of the performance gains, gathering disk usage for billing changes from parsing hundreds of thousands of maildirsize files (and du -s or equivalent for those really large maildirs, ugh) to a single sql query, Even more, we could explore enforcing quota on our mail gateways if they just need a sql connection for realtime usage info. So, as you can imagine, I would love to be able to use dictionary in a production environment :) And just to be clear, I am not trying to demand that any of this gets priority or anything, just trying to gauge your intentions and maybe throw out some ideas to show the potential value :) Congrats on hitting 1.0.0.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Timo Sirainen schrieb:> I think I won't do any actual releases until it's mostly feature > complete. Then maybe v1.1.alpha1 or v1.1.beta1. So if you want to test > it before then, use CVS or the nightly snapshots. > > I'm planning on keeping v1.1 almost completely compatible with v1.0. > There could be some minor configuration file changes, but for most > people v1.0's dovecot.conf should work with v1.1. > > I want to update index file handling to use less locks and update > dovecot.index file less often. The file formats would still stay > backwards compatible with v1.0. After this I'm hoping to get index files > working well with NFS even with attribute cache enabled. > > Dovecot v2.0 then brings incompatible index files and more or less > rewritten configuration file handling. It could still support old config > file format and settings, but the default will be somewhat different. > > I'm hoping to release the first alphas/betas in 2-3 months, with v1.1.0 > maybe even as early as next summer. The good thing here is that index > file code hasn't changed much since v1.0, so it should be stable. The > bad thing is that I've added a couple of completely new indexes. I'm > also quite busy for the next month, but I'm not sure how much it affects > my coding. :) > > The largest already implemented new features are: > > + Added support for IMAP UIDPLUS extension > + IMAP SORT: Sort keys are indexed, which makes SORT commands faster. > + IMAP THREAD: Threads are indexed into a dovecot.index.thread file. > It can usually be updated incrementally, so this makes THREAD fast. > + Added Dovecot-specific X-REFERENCES2 threading algorithm. > It's similar to REFERENCES, but it doesn't do base subject merging > and it sorts the threads by their newest message. > + When saving messages, update cache file immediately with the data > that we expect client to fetch later. Maildir-only currently. > + Mailbox list indexes. Mailbox metadata is stored there, so STATUS > commands can return synchronized mailboxes' metadata simply by > reading a single mailbox list index file. > - FIXME: Currently works only with Maildir++ layout. > + Expire plugin can be used to keep track of oldest messages in > specific mailboxes. A nightly run can then quickly expunge old > messages from the mailboxes that have them. The tracking is done > using lib-dict, so you can use either Berkeley DB or SQL database. > + Namespaces are supported everywhere now. > - FIXME: except by convert plugin > + Full text search indexing support with Lucene and Squat backends. > + OTP and S/KEY authentication mechanisms (by Andrey Panin). > + mbox and Maildir works with both Maildir++ and FS layouts. You can > change these by appending :LAYOUT=maildir++ or :LAYOUT=fs to > mail_location. > > Features that I'm planning on implementing: > > - Fully supported shared mailboxes and IMAP ACL extension > - Replace Squat FTS indexes with my new design > - Case-insensitive searches with non-ASCII text as well > - Maybe add support for all kinds of IMAP extensions that can be easily > supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe > even URLAUTH if I can figure out how it should work. > > If a feature can be implemented completely as a plugin, it could still > come in v1.1.beta stage, because it won't destabilize the rest of the > Dovecot anyway.Hi Timo, - - Fully supported shared mailboxes and IMAP ACL extension will be very nice will you include some quota warn code to lda like maildrop does ? - -- Mit freundlichen Gruessen Best Regards Robert Schetterer https://www.schetterer.org Munich/Bavaria/Germany -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGJTznfGH2AvR16oERAl+qAJ48qfm6XpfupgDCoWujZf3v3TNwJgCeJfeU EIbbGAv5F+GdzzBiD+bel5I=KQKu -----END PGP SIGNATURE-----
I'd like dovecot to have option '-e' to edit configs like postfix has. I understand dovecot configs are much more complex and have nested blocks. But may be double-colon notation to qualify identifiers by block names will work, like: --- dovecot -e 'socket listen::client::path=/tmp/dovecot-auth-client' -- Sergey Ivanov
On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote:> I'm planning on keeping v1.1 almost completely compatible with v1.0. > There could be some minor configuration file changes, but for most > people v1.0's dovecot.conf should work with v1.1.Please, this needs to be "Everyone's v1.0 dovecot.conf will work in v1.1." If you're going to change the configuration file format even in some subtle way, please bump the major version. Likewise with plugin support... if you're going to break API or ABI, please bump the major version. It's easy enough to avoid breaking compatibility gratuitously. People do not expect configuration files to need changing between minor releases and they'll be quite upset if things break. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070417/9c1e4239/attachment.bin>
> I want to update index file handling to use less locks and > update dovecot.index file less often. The file formats would > still stay backwards compatible with v1.0. After this I'm > hoping to get index files working well with NFS even with > attribute cache enabled.Music to my ears - as im sure with many other NFS sites. Regards __________________________________________ Dean Manners
On Tue, 17 Apr 2007, Timo Sirainen wrote:> I think I won't do any actual releases until it's mostly feature > complete. Then maybe v1.1.alpha1 or v1.1.beta1. So if you want to test > it before then, use CVS or the nightly snapshots.[...]> I'm hoping to release the first alphas/betas in 2-3 months, with v1.1.0 > maybe even as early as next summer. The good thing here is that index > file code hasn't changed much since v1.0, so it should be stable. The > bad thing is that I've added a couple of completely new indexes. I'm > also quite busy for the next month, but I'm not sure how much it affects > my coding. :)One question... I remember that such issue has been raised here some time ago, but I don't know if there were any decisions made... Is there a plan for using hard links in dovecot-LDA when the mail is going to be delivered to many recepients... In fact lack of such functionality is the only thing that holds me from switching in multiple locations to dovecot from cyrus-imap, which I really don't like (it requires LDAP, which I don't love as well ;) Greetz, -- Jacek Osiecki joshua at ceti.pl GG:3828944 "To nie logika, to polityka" (c) Kabaret pod Wydrwigroszem 2006
Firstly, congratutulations on the official 1.0; we are now running this in production. On Tue, 17 Apr 2007, Timo Sirainen wrote:> I'm hoping to release the first alphas/betas in 2-3 months, with v1.1.0 > maybe even as early as next summer. [...]Quick check: Is "next summer" envisaged as 2007 or 2008?> Features that I'm planning on implementing: > > - Fully supported shared mailboxes and IMAP ACL extension > - Replace Squat FTS indexes with my new design > - Case-insensitive searches with non-ASCII text as well > - Maybe add support for all kinds of IMAP extensions that can be easily > supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe > even URLAUTH if I can figure out how it should work.Could I put in a request for the "logfile consistency" item mentioned on April 3rd (and receiving some support)? See: http://www.dovecot.org/list/dovecot/2007-April/021532.html and subsequent thread. Many thanks. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :
Richard Laager wrote:> On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote: > >> I'm planning on keeping v1.1 almost completely compatible with v1.0. >> There could be some minor configuration file changes, but for most >> people v1.0's dovecot.conf should work with v1.1. >> > > Please, this needs to be "Everyone's v1.0 dovecot.conf will work in > v1.1." If you're going to change the configuration file format even in > some subtle way, please bump the major version. Likewise with plugin > support... if you're going to break API or ABI, please bump the major > version. It's easy enough to avoid breaking compatibility gratuitously. > People do not expect configuration files to need changing between minor > releases and they'll be quite upset if things break. > > Richard >I second that. Cheers, Hugo Monteiro. -- ci.fct.unl.pt:~# cat .signature Hugo Monteiro Email : hugo.monteiro at fct.unl.pt Telefone : +351 212948300 Ext.15307 Centro de Inform?tica Faculdade de Ci?ncias e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt apoio at fct.unl.pt ci.fct.unl.pt:~# _
Timo Sirainen wrote:> Features that I'm planning on implementing: > > - Fully supported shared mailboxes and IMAP ACL extension > - Replace Squat FTS indexes with my new design > - Case-insensitive searches with non-ASCII text as well > - Maybe add support for all kinds of IMAP extensions that can be easily > supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe > even URLAUTH if I can figure out how it should work. >Hello Timo, one thing i already discussed with you some time ago that would make some difference and open lots of possibilities, in my opinion, would be the ability to have a virtual INBOX that could be composed by a list of folders. That would make a world of difference to those who maintain a mixed service of pop and imap to their users. Just from the top of my head, two great possibilities would be able to 1 - One could use server side filtering (sieve, maildrop, etc) to separate junk from the INBOX to make things look nice for IMAP users, but still allow POP users to retrieve their marked messages and not miss any false positives. 2 - If the list of folders could be a wildcard, allow POP users to retrieve ALL their messages, even if they're also regular IMAP based webmail users. I'm sure other folks would find other ways to use such feature. Best regards, Hugo Monteiro. -- ci.fct.unl.pt:~# cat .signature Hugo Monteiro Email : hugo.monteiro at fct.unl.pt Telefone : +351 212948300 Ext.15307 Centro de Inform?tica Faculdade de Ci?ncias e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt apoio at fct.unl.pt ci.fct.unl.pt:~# _
Richard Laager wrote:> On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote: >> I'm planning on keeping v1.1 almost completely compatible with v1.0. >> There could be some minor configuration file changes, but for most >> people v1.0's dovecot.conf should work with v1.1.> Please, this needs to be "Everyone's v1.0 dovecot.conf will work in > v1.1." If you're going to change the configuration file format even in > some subtle way, please bump the major version.Well, there is room for argument here... I would call a 'minor' version going from 1.0 to 1.0.1. For these increments, I totally agree. However, going from 1.0.x to 1.1 is obviously a larger change, and I don't see a problem with *minor* config file changes, as long as they are well documented - and Timo has never failed to do that. In virtually every case, I imagine Timo would also provide backwards compatibility, so it would be a non-issue...> Likewise with plugin support... if you're going to break API or ABI, > please bump the major version. It's easy enough to avoid breaking > compatibility gratuitously. People do not expect configuration files > to need changing between minor releases and they'll be quite upset if > things break.Agree - but anyone who upgrades *anything* without reading the release notes is asking for trouble. -- Best regards, Charles
I'd suggest dropping any "alpha" or "beta" in the version string and treating "1.1.1" as the first public release. Use "1.1.0" as a prefix for pre-release versions and use a fourth number as your build number, like 1.1.0.123. The download page can explain the basics of this scheme so that newcomers don't assume it's a stable version. This has the virtue of not requiring any knowledge in downstream packaging systems about the strings you'll use to denote various generations of prerelease. For example, RPM won't need to know that "1.1.rc1" comes before "1.1.0". (Building that kind of logic into every packaging system is a pain, when you consider that every upstream source names things differently.) It also means that the public release won't be the buggy "dot-oh" that so many admins are accustomed to, but rather the dot-oh after all the known issues have been squeezed out, hence a dot-one. (Ie. it's a marketing trick to encourage adoption. ;))
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Timo,> Features that I'm planning on implementing: > > > - Fully supported shared mailboxes and IMAP ACL extensionfine... What do you think about LDAP (or SQL,...) queries for each userparameter? Make it easyer to implement dovecot at raised and/or complex structures. Mfg. Stefan Klatt - -- CaC, Computer and Communication Inhaber Stefan Klatt Triftstrasse 9 60528 Frankfurt Germany Tel.: +49-(0)172-6807809 Tel.: +49-(0)69-67808-900 Email: stefan.klatt at cac-netzwerk.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJ8pq+AkeCg4UPr4RAgDzAJ4yZLrxVjcN5k1EbbKWox46nRAF5gCglPRK lx+/J0CxeKOqYUe9ceYUjoo=g2CR -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: stefan.klatt.vcf Type: text/x-vcard Size: 220 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20070419/03b20402/attachment-0002.vcf>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Klatt schrieb:> Hi Timo, > >> Features that I'm planning on implementing: > > >> - Fully supported shared mailboxes and IMAP ACL extension > fine... > > What do you think about LDAP (or SQL,...) queries for each userparameter? > Make it easyer to implement dovecot at raised and/or complex structures. > > Mfg. > Stefan Klatt >As far i remember Timo answered that acl parameters in sql should be no problem but coding has no primary - -- Mit freundlichen Gruessen Best Regards Robert Schetterer https://www.schetterer.org Munich/Bavaria/Germany -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGJ92xfGH2AvR16oERArUMAJ9tpEPUw6XVHNux0fKw5SlNJva3MQCeMv/V ywA99qMY8+agMXDPoiP6dgc=kJp1 -----END PGP SIGNATURE-----
Justin McAleer writes:> On top of the performance gains, gathering disk usage for billing > changes from parsing hundreds of thousands of maildirsize files (and du > -s or equivalent for those really large maildirs, ugh) to a single sql > query,Not sure how difficult it would be, but that would be a very nice feature.