ANNOTATEMORE => METADATA and rfc 5464

[Bron Gondwana]

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.