W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

Re: Review of quota-06

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 19 Mar 2005 10:41:15 +0100
Message-ID: <423BF3BB.8000507@gmx.de>
To: ejw@soe.ucsc.edu
CC: w3c-dist-auth@w3.org

Jim Whitehead wrote:
> Julian Reschke writes:
> 
>>I think it would be a useful feature if a client could detect 
>>whether a write failed because of disk full rather than quota 
>>exceeded (Unix and
>>NFS4 status codes allow the same distinction, see RFC3530, 
>>"NFS4ERR_DQUOT" and "NFS4ERR_NOSPC").
> 
> 
> So, if I understand you correctly, you're advocating the addition of a
> single additional error code to cover the storage media full case?

My personal preference was to leave disk limits out of quota, and to 
define separate properties and precondition codes for them. However, if 
people feel this is overkill spec-wise, the ability to distinguish both 
cases when an operation fails would be welcome (and a cheap addition).

>>I'd like to understand why it's only optional on non-collections.
> 
> 
> Seems to me this is obvious. There are four cases:
> 
> 1) No support collections, no support others: You don't implement the
> specification

Yes.

> 2) Support collections, no support others: Frequent case, collections have
> quota information

Why wouldn't the non-collection resources have quota information?

> 3) Support collections, support others: Possibly frequent case, all
> resources give quota and used

Yes.

> 4) No support collections, support others: This case isn't allowed in the
> specification, but seems unlikely to me, since collection support is so
> useful

Yes.
> 
> So, is it that you think case #4 is useful, and want it to be allowed? Or
> are you seeking clarification text to be added to the draft?

I'd simply like the spec to be as simple as possible. Adding a special 
distinction for case 2 doesn't seem to be that useful.

>>So for a server that implements user-based quota (which IMHO 
>>is the most common way to implement it), DAV:quota-used-bytes 
>>usually will be the
>>*same* for a collection and it's members.
> 
> 
> Ah, good point.
> 
> Let me try again with some suggested text (the second paragraph is new, and
> based on your previous text):
> 
> "Since there are many factors that affect the storage used by a set of
> resources, including automatic compression, the size of associated metadata,
> and server-inserted content (such as that created by PHP code) in the
> on-the-wire representation of resources, clients are advised to not depend
> on the value of DAV:quota-used-bytes being the sum of the
> DAV:getcontentlength properties for resources contained by a collection. 
> 
> Additionally, because there may be a number of distinct but overlapping sets
> of resources for which a DAV:quota-used-bytes is maintained (see Section 4),
> there may be no correlation between the size of the resources in a
> collection and DAV:quota-used-bytes. For example a server that implements
> user-based quotas, DAV:quota-used-bytes usually will be the same for a
> collection and it's members."
> 
> If you have quibbles with this text, please suggest modifications to it in
> spec. language (it's easier than reading your mind :-)

No, the text is just fine. An alternative is not to say anything at all, 
but if we do say something, it at least needs to be correct :-)

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 19 March 2005 09:42:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:07 GMT