MESSAGE quota resource implemention
julien.coloos at gmail.com
Tue Sep 6 14:20:08 EDT 2011
Le 06/09/2011 19:48, Julien Coloos a écrit :
> 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.
When I said 'actual', I meant based on the upcoming mailbox index field.
But wait, I got a bit confused with the last point about playing along
with quota.sets. If what you discussed with Bron is that, in the end,
usage (re)computing will only be done with the quota utility (no more
automatic computing upon setquota, neither for getquota), then after
upgrading people shall call 'quota -f' once and for all and quota.sets
must disappear - and all resources must be written in the quota entry -,
otherwise users would need to call 'quota -f' on a given quotaroot each
time they set a new quota resource limit to a mailbox.
More information about the Cyrus-devel