On Thursday 06 March 2003 13:49, Brian Kolaci wrote:
> > > I'd be curious to see if Mr. Sam accepts such patches. I personally
> > > think that this new non-system domain quota feature is unnecessary,
> > > when system quotas are available, easily implemented, and a better
> > > solution. But enough people seemed to want it for some reason, and
> > > Brian did a very nice job of implementing it cleanly with his other
> > > vlimits functions, so I included it in my devel version. Notice that
> > > Ken has not yet signed off on this, so there's no guarantee that it
> > > will make it in the official release, anyway. So you might hold off
> > > on patching anything else, unless you (or anyone else) are prepared
> > > to maintain it.
> > Noted. I personally hope it makes production. Sounds like a good idea
> > to me, it just seems to require a ratification to the maildir++
> > standard.
> Seems unlikely. courier has no provision to store "domain" quotas,
> only user quotas. Like I said in my last email, it requires getting
> the domain quota from somewhere, and vdelivermail uses the vget_limits()
> API out of libvpopmail.a.
So the domain quotas aren't stored in a file, but rather in whatever database
backend you happen to be using?
I'd think that if the domain quotas could be stored in a file, that a ratification
could be made to the maildir++ standard. Perhaps the maildirsize file could contain
a reference to the location of the domain quota file. This would be quite flexible
What do you think?
Either way, I think this functionality needs to be implemented in a way
that Courier-IMAP and other programs can live with. It should be standardized,
otherwise vpopmail will be implementing a feature that no-one else can
realistically use without linking vpopmail's libraries into their code
(which I mentioned in another thread as being a bit of a pain sometimes).
Jesse Guardiani, Systems Administrator
WingNET Internet Services,
P.O. Box 2605 // Cleveland, TN 37320-2605
423-559-LINK (v) 423-559-5145 (f)
We are actively looking for companies that do a lot of long
distance faxing and want to cut their long distance bill by
up to 50%. Contact [EMAIL PROTECTED] for more info.