MESSAGE quota resource implemention
gnb at fastmail.fm
Tue Sep 6 04:23:01 EDT 2011
On 06/09/11 02:55, Julien Coloos wrote:
> Le 05/09/2011 06:12, Greg Banks a écrit :
>> Julien, I think we agreed on everything else, right? I'm looking
>> forward to your next iteration.
> After picking your 'uquota_t removal' commit, I also removed it on my
> end, and changed the code according to our previous discussions.
Ok, I've read these:
commit "Remove uquota_t"
commit "Minor code cleanup"
commit "Do not mess with mailbox index struct fields upon deleting."
commit "When tracking quota usage changes, check all resources."
and it all looks fine to me, except that:
a) my commit "Make quota -f less racy" is going to cause lots of clashes
b) Bron and I both think that your commit "Compute each quota resource
upon setting it for the first time." is unnecessary, given that
i) quota -f doesn't suck now, and
ii) soon, all of the quota-able quantities will be tracked in fields
in the index header.
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.
> an helper function which fills a quota_t array with the current messages
> usage from mailbox struct made the code a bit cleaner and more generic :)
Yes, I'm very pleased with that :)
> I still have to look for transferring limits upon DUMP/UNDUMP. And for
> the time being, I still kept the quota.sets thing (we will see later
> if we can do it more smartly).
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 :)
More information about the Cyrus-devel