MESSAGE quota resource implemention

[Julien Coloos]

Le 06/09/2011 10:23, Greg Banks a écrit :
>
> So I think we'll need another round, sorry :(  Given that the
> annotations quota is broken and I'll be reimplementing it anyway, you
> may as well ignore QUOTA_ANNOTSTORAGE in all commits, and leave out the
> function annotatemore_computequota() for now.  We'll use something very
> much like it for reconstruct later.  I'm hoping to be able to pull your
> next round of changes into my annotate branch before I reimplement the
> annotation quota in the next few days.
>
If the new code is capable of returning actual resource usages upon 
getquota (I think Bron wanted it that way), then I guess I can drop some 
more of the functions I added (annotatemore_computequota, but also 
mboxlist_updatequota and associated code including the quota.sets[]; 
then maybe I could also change the code as proposed earlier and prevent 
writing of resource limit in quota entry if it is QUOTA_UNLIMITED). Will 
look at it tomorrow.

Worked on DUMP/UNDUMP today: 
https://github.com/worldline-messaging/cyrus-imapd/commit/45148b20a4f2343d72aa7436e7255a92508d7bf8
I used an IMAP list to send data, as for annotations. For future usages, 
maybe the UNDUMP code could try to skip IMAP lists if it finds any 
instead of the expected file content LITERAL ? (to prevent breaking 
compatibility too many times, in case other things would need to be 
transmitted this way through DUMP/UNDUMP).

By the way, I noticed that UNDUMPing annotations fails for now (function 
annotate_state_write uses 'int_mboxname' in the annotation state struct, 
but it is NULL in this context).

>
> I'm still not convinced we'll need quota.sets[], but I'll play along.
>
> Thanks again for your work, and sorry that my annotate branch wasn't
> quite as stable a base as you first thought :)
No problem, I was somehow prepared to that kind of scenario :)


Regards
Julien