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
