referring quota commands

[Wesley Craig]

Find the patch implementing quota proxying below.  My analysis of the  
"won't retain that privilege" comment: if proxyadmin and admin are  
the same, then the admin *will* retain privs during proxy.  If not,  
then proxying is the wrong result, and the admin will need to connect  
directly to the backend, either because it knows which backend to  
connect to, or because it's following a referral.

This version checks "supports_referrals" to decide whether to send a  
referral, which is the same check that, for instance, CREATE for a  
top-level mailbox uses.  Another option might be appropriate, e.g.,  
proxyd_allow_admin_referrals, to specifically permit commands that  
won't retain privileges over proxy.  This version, however, is simpler.

Any comments before I commit it?

:wes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyrus-imapd-quota-referral.diff
Type: application/octet-stream
Size: 2860 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20080918/e5b2b120/attachment.obj 
-------------- next part --------------

On 14 Jul 2008, at 14:34, Wesley Craig wrote:
> Is there some reason why the quota commands aren't fully proxied?   
> E.g., this comment from cmd_getquotasroot:
>
>             /* If they are an admin, they won't retain that  
> privledge if we
>              * proxy for them, so we need to refer them -- even if  
> they haven't
>              * told us they're able to handle it. */
>             imapd_refer(tag, server, name);
>
> doesn't make much sense to me.  I guess I could make my quota  
> setting agent understand the referrals, but the proxy code in  
> imapd.c already has a nice framework for caching connections, etc.   
> It seems like implementing proxy for cmd_setquota, cmd_getquota,  
> and cmd_getquotaroot would be less work and allow provisioning  
> systems to work more seamlessly out of the box with Cyrus.  Any  
> comments?