[Dovecot] dovecot-stable branch
To confuse Dovecot versioning even more, I've added "dovecot-stable" module into CVS. This is a version of Dovecot before the recent keyword changes but with several bugfixes backported to it. It's thought to be mostly stable.
I intend to keep it updated with important bugfixes and with other simple bugfixes. Although I'm not sure if I'll make a large code base upgrade once keyword changes are stable.
This is mostly meant for people who _really_ want to use 1.0-test codebase in production right now. Perhaps it's already more stable than 0.99.x, but upgrading should probably be made easier for v1.0.
The dovecot-stable module itself is just a hack that will go away at some point. Once the main codebase is stable enough for v1.0 beta release, I'll make a stable branch instead in the main dovecot module (and probably with different RCS than CVS).
Le 31.01.2005 18:23, Timo Sirainen a écrit :
To confuse Dovecot versioning even more, I've added "dovecot-stable" module into CVS. This is a version of Dovecot before the recent keyword changes but with several bugfixes backported to it. It's thought to be mostly stable.
I intend to keep it updated with important bugfixes and with other simple bugfixes. Although I'm not sure if I'll make a large code base upgrade once keyword changes are stable.
What are exactly the keywords made for ? I'm not familiar with this...
This is mostly meant for people who _really_ want to use 1.0-test codebase in production right now. Perhaps it's already more stable than 0.99.x, but upgrading should probably be made easier for v1.0.
That's great, will you make nightly CVS snapshots of this module as well ?
Regards,
Nico Le repos, le repos, trésor si précieux Qu'on en faisait jadis le partage des Dieux ? -+- Jean de La Fontaine (1621-1695), L'Homme qui court après la Fortune (Fables VII.11) -+-
On Mon, 2005-01-31 at 18:33 +0100, Nicolas STRANSKY wrote:
Le 31.01.2005 18:23, Timo Sirainen a écrit :
To confuse Dovecot versioning even more, I've added "dovecot-stable" module into CVS. This is a version of Dovecot before the recent keyword changes but with several bugfixes backported to it. It's thought to be mostly stable.
I intend to keep it updated with important bugfixes and with other simple bugfixes. Although I'm not sure if I'll make a large code base upgrade once keyword changes are stable.
What are exactly the keywords made for ? I'm not familiar with this...
Mozilla/Thunderbird calls these labels. They are just message flags which client has named, usually compatible with itself only. Most clients don't support them at all.
This is mostly meant for people who _really_ want to use 1.0-test codebase in production right now. Perhaps it's already more stable than 0.99.x, but upgrading should probably be made easier for v1.0.
That's great, will you make nightly CVS snapshots of this module as well ?
Thought I'd wait until someone requests them. I guess so then. http://dovecot.org/nightly/stable/
Timo Sirainen wrote:
This is mostly meant for people who _really_ want to use 1.0-test codebase in production right now. Perhaps it's already more stable than 0.99.x, but upgrading should probably be made easier for v1.0.
That's great, will you make nightly CVS snapshots of this module as well ?
Thought I'd wait until someone requests them. I guess so then. http://dovecot.org/nightly/stable/
What about a new -test build? I wanna see if my bug is fixed, or should I dare a nightly snapshot? :)
// Tom
On Mon, 2005-01-31 at 19:44 +0200, Timo Sirainen wrote:
On Mon, 2005-01-31 at 18:33 +0100, Nicolas STRANSKY wrote:
Le 31.01.2005 18:23, Timo Sirainen a écrit :
To confuse Dovecot versioning even more, I've added "dovecot-stable" module into CVS. This is a version of Dovecot before the recent keyword changes but with several bugfixes backported to it. It's thought to be mostly stable.
I intend to keep it updated with important bugfixes and with other simple bugfixes. Although I'm not sure if I'll make a large code base upgrade once keyword changes are stable.
What are exactly the keywords made for ? I'm not familiar with this...
Mozilla/Thunderbird calls these labels. They are just message flags which client has named, usually compatible with itself only. Most clients don't support them at all.
Some keywords are standardized- $MDNSent for example (as a replacement for Recent for client-side filtering).
Some keywords are "common"- like Mozilla's Junk and NotJunk keywords. I expect these to become more popular....
I wish keywords could be used as a replacement for UIDs that'd never change ( e.g. KEYWORD $MID=989498397.32217.wumpus,S=6013 ), but most IMAP servers don't seem to optimize SEARCH KEYWORD for this.
I wish keywords could be used as a replacement for folders such that a message could be in multiple folders, but IMAP clients would need a way to fetch all the keywords efficiently. Perhaps just adding them to the PERMANENTFLAGS response would be enough...
Some thought should go into the support of clients that support this kind of behavior, and provide a way to map "folders" and "keywords" in both directions.
Keywords is a "hack" for most IMAP servers, and this is bad because it's one of the sanest mechanisms in all of IMAP...
-- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
On Tue, 2005-02-01 at 12:00 -0500, Geo Carncross wrote:
I wish keywords could be used as a replacement for UIDs that'd never change ( e.g. KEYWORD $MID=989498397.32217.wumpus,S=6013 ), but most IMAP servers don't seem to optimize SEARCH KEYWORD for this.
I don't think that is a good way to use keywords. Keywords are required (I think) to be shown in PERMANENTFLAGS reply and then it would contain every message's UID.
Also servers' internal implementations usually treat them as flags which are reused between multiple messages. I've tried to make Dovecot's implementation so that setting a separate keyword for each message wouldn't be too slow or memory hungry, but in index file they're still stored in a bitmask, so it uses 4 bytes per 32 keywords for all messages.
ANNOTATE extension is really where this belongs. I'll probably implement it at some point, but I don't really know where I'd store them. Perhaps I should finally use Berkeley DB for that.. or SQL as alternative. Although having some simpler (but slower) choice would be nice too. So I guess I'll just use some generic key -> value mapper API which has different backends..
I wish keywords could be used as a replacement for folders such that a message could be in multiple folders, but IMAP clients would need a way to fetch all the keywords efficiently. Perhaps just adding them to the PERMANENTFLAGS response would be enough...
Some thought should go into the support of clients that support this kind of behavior, and provide a way to map "folders" and "keywords" in both directions.
I've recently discussed about this in private mail with a few people. Virtual folders implemented with keywords would be a nice idea. Each keyword would map to virtual folder under the mailbox.
"?keyword" would mean the keyword was set automatically by some virtual folder rule. It's removed if the rule is changed and doesn't match anymore.
"keyword" means the message was explicitly copied into the virtual folder and it's not removed automatically.
"-keyword" means the message was explicitly moved away from the virtual folder and it's not added again automatically by any rule.
\Deleted + EXPUNGE probably would expunge the message from all virtual folders. I'm not sure how the "moving away" would work then.. COPY + \Deleted + EXPUNGE sequence somehow should remember that the message was wanted to be expunged only from that mailbox.
I think ?keyword should be shown to client as keyword without the ? character and -keywords not at all.
On Tue, 2005-02-01 at 19:31 +0200, Timo Sirainen wrote:
On Tue, 2005-02-01 at 12:00 -0500, Geo Carncross wrote:
I wish keywords could be used as a replacement for UIDs that'd never change ( e.g. KEYWORD $MID=989498397.32217.wumpus,S=6013 ), but most IMAP servers don't seem to optimize SEARCH KEYWORD for this.
I don't think that is a good way to use keywords. Keywords are required (I think) to be shown in PERMANENTFLAGS reply and then it would contain every message's UID.
Not if \* is listed in PERMANENTFLAGS.
I'm not saying it's the best way to go about this (ANNOTATE is new to me and certainly looks a lot better)
Also servers' internal implementations usually treat them as flags which are reused between multiple messages. I've tried to make Dovecot's implementation so that setting a separate keyword for each message wouldn't be too slow or memory hungry, but in index file they're still stored in a bitmask, so it uses 4 bytes per 32 keywords for all messages.
That's terrible! Fortunately existing clients don't have heavy-use of keywords... I agree, ANNOTATE certainly seems like the best place for this.
ANNOTATE extension is really where this belongs. I'll probably implement it at some point, but I don't really know where I'd store them. Perhaps I should finally use Berkeley DB for that.. or SQL as alternative. Although having some simpler (but slower) choice would be nice too. So I guess I'll just use some generic key -> value mapper API which has different backends..
SQLite works well- and you'd get it's indexer for free. Separate backends are fine. I don't entrust my data to Berkeley DB however...
I wish keywords could be used as a replacement for folders such that a message could be in multiple folders, but IMAP clients would need a way to fetch all the keywords efficiently. Perhaps just adding them to the PERMANENTFLAGS response would be enough...
Some thought should go into the support of clients that support this kind of behavior, and provide a way to map "folders" and "keywords" in both directions.
I've recently discussed about this in private mail with a few people. Virtual folders implemented with keywords would be a nice idea. Each keyword would map to virtual folder under the mailbox.
"?keyword" would mean the keyword was set automatically by some virtual folder rule. It's removed if the rule is changed and doesn't match anymore.
"keyword" means the message was explicitly copied into the virtual folder and it's not removed automatically.
"-keyword" means the message was explicitly moved away from the virtual folder and it's not added again automatically by any rule.
\Deleted + EXPUNGE probably would expunge the message from all virtual folders. I'm not sure how the "moving away" would work then.. COPY + \Deleted + EXPUNGE sequence somehow should remember that the message was wanted to be expunged only from that mailbox.
I think ?keyword should be shown to client as keyword without the ? character and -keywords not at all.
Perhaps reference counting the messages would be adequate. Using $MDNStatus, ?keyword would be unnecessary, and likewise, -keyword as well. One could simply use KEYWORD and UNKEYWORD and keep a reference- count of how many of these vfolder-like keywords are associated with a message and EXPUNGE can only prune it if \Deleted is set and it's reference count is Zero (i.e. it's not in INBOX or Archive or another "real" folder).
Otherwise, setting \Deleted on a message would remove the vfolder keyword or set the "-xxx" where xxx is the folder that the message physically exists in.
In this method, Thunderbird would suddenly see Junk and NotJunk folders. What is done about SUBSCRIBE and UNSUBSCRIBE? Do they always start unsubscribed? That's certainly easier, but if they start subscribed, is it really important to "remember" that keyword if all messages have been removed from that keyword?
A client interested in discerning keywords from folders can do so by examining PERMANENTFLAGS and the folder list. This causes problems if a user creates a "Junk" folder themselves- in which case, what does the Junk keyword refer to?
-- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
On Mon, 31 Jan 2005, Timo Sirainen wrote:
To confuse Dovecot versioning even more, I've added "dovecot-stable" module into CVS. This is a version of Dovecot before the recent keyword changes but with several bugfixes backported to it. It's thought to be mostly stable.
Should distro packagers use this or stick to 0.99.x?
-- Jaldhar H. Vyas jaldhar@debian.org La Salle Debain - http://www.braincells.com/debian/
On 1.2.2005, at 14:54, Jaldhar H. Vyas wrote:
To confuse Dovecot versioning even more, I've added "dovecot-stable" module into CVS. This is a version of Dovecot before the recent keyword changes but with several bugfixes backported to it. It's thought to be mostly stable.
Should distro packagers use this or stick to 0.99.x?
Upgrading from 0.99.x to 1.0-tests doesn't work without changes to configuration fie. I was thinking about trying to make some backwards compatibility changes before v1.0 final. And there probably will still be more configuration changes before v1.0. So I'd say keep 0.99.x for now.
On 01-02-2005 14:59, Timo Sirainen wrote:
On 1.2.2005, at 14:54, Jaldhar H. Vyas wrote:
To confuse Dovecot versioning even more, I've added "dovecot-stable" module into CVS. This is a version of Dovecot before the recent keyword changes but with several bugfixes backported to it. It's thought to be mostly stable.
Should distro packagers use this or stick to 0.99.x?
Upgrading from 0.99.x to 1.0-tests doesn't work without changes to configuration fie. I was thinking about trying to make some backwards compatibility changes before v1.0 final. And there probably will still be more configuration changes before v1.0. So I'd say keep 0.99.x for now.
That is not a problem with the current installation of dovecot in Debian, IMHO: The config file needs editing to work anyway (it is not using debconf anymore like earlier) and the packaging system takes care of warning if the older file was hand-tuned and thus needs new tweaking (the configuration files are registered as "conffiles" with Debian).
So if upgrading the configuration file is the only issue, I'd say go for it (for Debian-based systems at least).
As a sidenote: It could be helpful for the Debian maintainance if dovecot supported including additional config snippets. That way options like ports to listen on (that depends on the daemons installed and the security policy of the site) could be handled separately from the main config file (with lots of options that do not need tweaking for most users). For Debian it would mean that configuration could be split between automatic package installation routines (using debconf) and more advanced and/or esoteric stuff hand-tunable by the local admin.
- Jonas
--
- Jonas Smedegaard - idealist og Internet-arkitekt
- Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
On Tue, 2005-02-01 at 15:19 +0100, Jonas Smedegaard wrote:
That is not a problem with the current installation of dovecot in Debian, IMHO: The config file needs editing to work anyway (it is not using debconf anymore like earlier) and the packaging system takes care of warning if the older file was hand-tuned and thus needs new tweaking (the configuration files are registered as "conffiles" with Debian).
So if upgrading the configuration file is the only issue, I'd say go for it (for Debian-based systems at least).
Another reason why not to upgrade is you'd lose your old keywords. The code is there in 0.99.x but not in 1.0-tests.
participants (6)
-
Geo Carncross
-
Jaldhar H. Vyas
-
Jonas Smedegaard
-
Nicolas STRANSKY
-
Timo Sirainen
-
Tom Sommer