Re: ANNOTATEMORE = METADATA and rfc 5464
On Tue, Nov 17, 2009 at 06:37:13PM -0500, Ken Murchison wrote: Bron Gondwana wrote: On Tue, Nov 17, 2009 at 04:17:51PM -0500, Ken Murchison wrote: Bron Gondwana wrote: On Tue, Nov 17, 2009 at 09:03:11AM -0500, Ken Murchison wrote: What is your new format proposal? I'll see :) Not sure yet - but mainly not sizeof(unsigned long)! If we make a wholesale change to the database, perhaps this might be something we put in the 2.4 branch. It already has some partial/complete extensions like QRESYNC, LIST-EXTENDED, URLAUTH=BINARY and COMPRESS (which I backported to 2.3). I was also thinking that although the charset changes have been fully tested at Fastmail that it too might be a candidate for 2.4. Yeah, fair enough! I did commit them to CVS, but it's easy enough to back them out and commit to a branch instead. Do we have a roadmap for what else people want on the 2.4 branch? I'd be happy to put a bit more effort into polishing up those features that are there so we can ship a 2.4 soonish. Say by April next year, which gives us 6 months to prepare. My original vision for 2.4 was to be compliant with the LEMONADE v2 profile. Sounds like a good plan :) At this point is can morph into anything we want. Some of the 2.4 features required changes that I felt were too in depth to put into a relatively stable 2.3. I'm pretty close to having the time to dive back into the 2.4 code. The first thing that needs to be done is to merge all of the new 2.3 stuff into 2.4. Sure. I'm happy to put the more unstable stuff (even including the charset changes) into 2.4. I just want to have some idea that they won't get stuck waiting for some lemonade scented towlettes forever. If we commit to something like 2.4 will ship with whatever features we have ready in April 2010 then we have a decent timeline to figure out what we'll actually have time to support, and focus on getting that stable. In particular, that's a good time for all the format changes to land all at once, and potentially new defaults for a bunch of config values that have occured over the years. In particular things like collation order for the mailboxes.db should just be fixed. Dump and restore your DB and do it this way! In general I'd like to simplify configuration where possible even at the expense of backwards compatibility. We could have a config_version: 2.4 key which needs to be changed over major version differences, and keep configs compatible within the major versions. (2.x that is) Bron. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ANNOTATEMORE = METADATA and rfc 5464
Hi Bron, thanks for looking into the annotation/metadata stuff. So I'm thinking: create a new metadata.db, require a conversion on upgrade from annotations.db. I had a look, and none of our servers had ANY annotations until I added a /comment to my INBOX for testing. Just to be sure: do you plan to change the current annotatemore-code so that it will access the new database and an old client still using annotatemore will still work? Does anybody out there use annotations much? Does anybody know any code that would be broken by changing the way annotations are done? Given that there is code to convert the old annotations.db to metadata.db I don't see any problems for us. Our backup code will probably need some tweaking, but when the new db format is more sane than the current mess I don't see any problems with that. Kind regards, Gerd -- Address (better: trap) for people I really don't want to get mail from: jo...@cactusamerica.com Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ANNOTATEMORE = METADATA and rfc 5464
Bron Gondwana schrieb: Does anybody out there use annotations much? Does anybody know any code that would be broken by changing the way annotations are done? We are using annotations to define expire times for spam folders and to define mailboxes to be indexed by squatter. Approx. 4 annotations are always set. -- Pascal Gienger University of Konstanz, IT Services Department (Rechenzentrum) Electronic Communications and Web Services Building V, Room V404, Phone +49 7531 88 5048, Fax +49 7531 88 3739 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ANNOTATEMORE = METADATA and rfc 5464
--On 17. November 2009 23:28:49 +1100 Bron Gondwana br...@fastmail.fm wrote: Does anybody out there use annotations much? Not much, but I have used them a few times to use with expire. Anyway, I'd be OK with an upgrade procedure. -- .:.Sebastian Hagedorn - RZKR-R1 (Gebäude 52), Zimmer 18.:. .:.Regionales Rechenzentrum (RRZK).:. .:.Universität zu Köln / Cologne University - ✆ +49-221-478-5587.:. p7sv3fQoyoWmx.p7s Description: S/MIME cryptographic signature Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ANNOTATEMORE = METADATA and rfc 5464
On Tue, 2009-11-17 at 23:28 +1100, Bron Gondwana wrote: I'm in the process of implementing rfc 5464, which is what the ANNOTATEMORE drafts turned into. Unfortunately, Cyrus' support is an early draft, before the paths to everything were changed and the commands were renamed. It would be great to be complient, and there is software out there like Kolab which would benefit from it. Also, the database format is pretty nasty - complete with nulls embedded in keys and other fun stuff (like platform dependent type lengths codified in the format, ick) So I'm thinking: create a new metadata.db, require a conversion on upgrade from annotations.db. I had a look, and none of our servers had ANY annotations until I added a /comment to my INBOX for testing. Does anybody out there use annotations much? Does anybody know any code that would be broken by changing the way annotations are done? Just for an occasional comment and expire values. Nothing where we couldn't dump, parse, and re-apply. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ANNOTATEMORE = METADATA and rfc 5464
What is your new format proposal? Bron Gondwana wrote: I'm in the process of implementing rfc 5464, which is what the ANNOTATEMORE drafts turned into. Unfortunately, Cyrus' support is an early draft, before the paths to everything were changed and the commands were renamed. It would be great to be complient, and there is software out there like Kolab which would benefit from it. Also, the database format is pretty nasty - complete with nulls embedded in keys and other fun stuff (like platform dependent type lengths codified in the format, ick) So I'm thinking: create a new metadata.db, require a conversion on upgrade from annotations.db. I had a look, and none of our servers had ANY annotations until I added a /comment to my INBOX for testing. Does anybody out there use annotations much? Does anybody know any code that would be broken by changing the way annotations are done? Thanks, Bron. -- Kenneth Murchison Systems Programmer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ANNOTATEMORE = METADATA and rfc 5464
On Tue, Nov 17, 2009 at 09:03:11AM -0500, Ken Murchison wrote: What is your new format proposal? I'll see :) Not sure yet - but mainly not sizeof(unsigned long)! Bron. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ANNOTATEMORE = METADATA and rfc 5464
Bron Gondwana wrote: On Tue, Nov 17, 2009 at 09:03:11AM -0500, Ken Murchison wrote: What is your new format proposal? I'll see :) Not sure yet - but mainly not sizeof(unsigned long)! If we make a wholesale change to the database, perhaps this might be something we put in the 2.4 branch. It already has some partial/complete extensions like QRESYNC, LIST-EXTENDED, URLAUTH=BINARY and COMPRESS (which I backported to 2.3). I was also thinking that although the charset changes have been fully tested at Fastmail that it too might be a candidate for 2.4. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ANNOTATEMORE = METADATA and rfc 5464
On Tue, Nov 17, 2009 at 11:28:49PM +1100, Bron Gondwana wrote: Does anybody out there use annotations much? Does anybody know any code that would be broken by changing the way annotations are done? I'm the only one who uses it here ;) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Rudy Gevaert rudy.geva...@ugent.be tel:+32 9 264 4734 Directie ICT, afd. Infrastructuur Direction ICT, Infrastructure dept. Groep Systemen Systems group Universiteit Gent Ghent University Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ANNOTATEMORE = METADATA and rfc 5464
On Tue, Nov 17, 2009 at 04:17:51PM -0500, Ken Murchison wrote: Bron Gondwana wrote: On Tue, Nov 17, 2009 at 09:03:11AM -0500, Ken Murchison wrote: What is your new format proposal? I'll see :) Not sure yet - but mainly not sizeof(unsigned long)! If we make a wholesale change to the database, perhaps this might be something we put in the 2.4 branch. It already has some partial/complete extensions like QRESYNC, LIST-EXTENDED, URLAUTH=BINARY and COMPRESS (which I backported to 2.3). I was also thinking that although the charset changes have been fully tested at Fastmail that it too might be a candidate for 2.4. Yeah, fair enough! I did commit them to CVS, but it's easy enough to back them out and commit to a branch instead. Do we have a roadmap for what else people want on the 2.4 branch? I'd be happy to put a bit more effort into polishing up those features that are there so we can ship a 2.4 soonish. Say by April next year, which gives us 6 months to prepare. Bron. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ANNOTATEMORE = METADATA and rfc 5464
Bron Gondwana wrote: On Tue, Nov 17, 2009 at 04:17:51PM -0500, Ken Murchison wrote: Bron Gondwana wrote: On Tue, Nov 17, 2009 at 09:03:11AM -0500, Ken Murchison wrote: What is your new format proposal? I'll see :) Not sure yet - but mainly not sizeof(unsigned long)! If we make a wholesale change to the database, perhaps this might be something we put in the 2.4 branch. It already has some partial/complete extensions like QRESYNC, LIST-EXTENDED, URLAUTH=BINARY and COMPRESS (which I backported to 2.3). I was also thinking that although the charset changes have been fully tested at Fastmail that it too might be a candidate for 2.4. Yeah, fair enough! I did commit them to CVS, but it's easy enough to back them out and commit to a branch instead. Do we have a roadmap for what else people want on the 2.4 branch? I'd be happy to put a bit more effort into polishing up those features that are there so we can ship a 2.4 soonish. Say by April next year, which gives us 6 months to prepare. My original vision for 2.4 was to be compliant with the LEMONADE v2 profile. At this point is can morph into anything we want. Some of the 2.4 features required changes that I felt were too in depth to put into a relatively stable 2.3. I'm pretty close to having the time to dive back into the 2.4 code. The first thing that needs to be done is to merge all of the new 2.3 stuff into 2.4. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
