[Dovecot] Dovecot METADATA support

[Bruce Marriner]

On Wednesday, March 27, 2013 02:25 PM CDT, Timo Sirainen <tss at iki.fi> wrote: 
 > On 27.3.2013, at 16.34, Bruce Marriner <bruce+dovecot at bmts.us> wrote:
> 
> > I've been trying to work with dovecot metadata plugin and posted a question here related to that a few days ago here :
> > http://www.dovecot.org/list/dovecot/2013-March/089241.html
> 
> The patch is now in v2.1 hg, so will be in v2.1.16.

Thank you.

> >>> Dovecot is getting close to having native METADATA support.
> > 
> > I am very curious about this.  When is "getting close" and I would guess this will be for v2.2?  Will this support be the same as the dovecot-metadata-plugin in hg or something completely different?  I'm sorry if I'm asking questions that have already been answered.
> 
> The metadata plugin started with implementing the IMAP commands and kind of ignored the difficult parts of fitting it in with everything. The stuff that is in Dovecot now handles most of the difficult parts, but the IMAP commands are missing. There are still two somewhat difficult things missing:
> 
>  * Where/how to keep track of metadata quota to prevent abuse? Maybe some limits to number of entries, max. bytes total in entries, max. bytes per entry. Although the last one only is useful for those backends that can't handle large entry sizes.
> 
> ( * Maybe there should be a new dict backend that can handle both small and large entries more optimally.. Then again some nosql dict backend would probably work well too.)
> 
>  * Currently it's configured via mail_attribute_dict, which can e.g. point to a file in user's home directory. How to handle shared metadata in shared folders? Should userA just be accessing userB's dict file? Where are metadata stored for public folders that have no owner? Should there be two dict settings for private and public dict? (The last, or maybe all, would be a non-issue if I had already implemented my idea of having only one dict configuration where different prefixes could be mapped to completely different locations/backends/etc.)
> 
 
These questions I can't help much with, sadly.  But I am more then willing to help with any testing, debugging, etc that I can possibly provide when there's something to test :).  I really do appreciate your work on this Timo!