- From: Chris Sharp <csharp@apple.com>
- Date: Thu, 11 Dec 2003 10:30:29 -0800
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: w3c-dist-auth@w3.org, Brian Korver <briank@xythos.com>
Just getting around to understanding this thread. I totally agree, the quota-assigned-bytes seems unnecessary and confusing. On another note, I think there needs to be some clarification the way quota-available-bytes and quota-used-bytes work. Example: Initial State of Repository with a Quota management system: DAV:quota-available-bytes DAV:quota-used-bytes /A 95MB 5MG <--- used for somewhere for something /A/UploadDirectory 10MB 0 A new 5MB resource is created at /A/UploadDirectory/new5MBFile: DAV:quota-available-bytes DAV:quota-used-bytes /A 90MB 10MB /A/UploadDirectory 5MB 5MB Pretty clear, however, if there is no quota differentiation on /A/UploadDirectory, the current draft of the RFC makes quota-used-bytes, which is really inherited from its parent, incongruent with quota-available-bytes on the same resource. A diagram is in order: Initial State of Repository with a Quota management system: (quota system on /A only) DAV:quota-available-bytes DAV:quota-used-bytes /A 95MB 5MG A new 5MB resource is created at /A/UploadDirectory/new5MBFile: DAV:quota-available-bytes DAV:quota-used-bytes /A 90MB 10MB /A/UploadDirectory 90MB 5MB The sum of quota-available-bytes and quota-used-bytes is 95 on /A/UploadDirectory and not 100! Logically, if you get a request for quota-available-bytes on a resource /A/UploadDirectory and the quota is actually enforced on the parent, that you would essentially walk up the tree until you found an appropriate "mount point" based quota requirement. If this is true, the quota-used-bytes should do the same thing. Meaning, quota-used-bytes on /A/UploadDirectory would be the same as quota-used-bytes /A if /A/UploadDirectory did not contain a more specific quota rule. This is also an efficiency win for implementors. If an implementation has to support quota-used-bytes on an arbitrary URL, it is impractical to think that quota-used-bytes could be incrementally adjusted and would necessarily need to be calculated on-the-fly, which does not scale well for most implementations. How NFSv4 handles this situation? Also, under the "Notes" section, "What clients should expect" seems to have a sentence which is not grammatically correct. "This allows the space used by /~milele/public/ to be as large as the quota on /~milele/ allows (depending on the other contents of /~milele/) even if the quota on /~milele/ is changed." Regards, Chris. On Nov 14, 2003, at 2:27 AM, Stefan Eissing wrote: > > Brian, > > I put my mind into blank slate mode and read the draft 2 for the first > time. > > I think it is a big improvment from where we started from. One item I > found > confusing though and that is the example for DAV:quota-assigned-bytes > (and the mental model behind the example). > > The draft seems to say that /A and /A/B have separate > DAV:quota-assigned-bytes > properties, however they are in the same "set of collections" when the > value > of DAV:quota-available-bytes/DAV:quota-used-bytes is computed. > > (See definition of "set" in the explanation to DAV:quota-used-bytes - > seems to > be a copy from the NFS spec.) > > In NFS-Quota, the model seems to be simple: each quota applies to a set > of collections/files and each member of this set would report the same > quota properties. > > In WebDAV-quota (draft-2): there is a separate quota for each > collection > (e.g. the assigned-bytes), but available-/used-bytes are the same for > resources in the same set. > > Two Problems come to my mind now: > 1) If a collection of the "set" has the DAV:quota-assigned-bytes not > explicitly set, what value would it report? Say for /A/C, /A/B/D and > /E (all in the same set)? > > 2) If a client wants to increase DAV:quota-available-bytes in a certain > collection, it has to increase the DAV:quota-assigned-bytes. But in > your example: increasing assigned-bytes on /A/B will not have any > effect on the DAV:quota-available-bytes. What is a generic client > supposed > to do then? > > Best Regards, Stefan > > Am 13.11.2003 um 22:06 schrieb Brian Korver: > >> >> On Thursday, November 13, 2003, at 01:14 PM, Julian Reschke wrote: >>> Brian, >>> >>> when I re-raised these issues, I *did* read the current draft. So I >>> think it's up to you to go back to the mailing list discussion and >>> explain why the concerns raised by Stefan and myself aren't valid. >>> >>> Julian >> >> Julian, >> >> I'm planning to do so in today's meeting, but to restate for the >> mailing list, >> Stefan pointed out that if we used quota-limit, then quota-limit >> would not be >> a fixed value (which is the reason we defined things in terms of >> quota-limit >> to begin with). Thus, instead of quota-limit, the new draft uses >> NFS's >> quota-available. This has the semantics that it isn't fixed. >> Problem solved. >> Note, quota-available is consistent with the rest of the the quota >> definitions >> we pulled from NFS, so it's conceptually attractive too. >> >> I still don't know what you find confusing, so I can't comment on >> that yet. >> >> -brian >> briank@xythos.com >
Received on Thursday, 11 December 2003 13:30:32 UTC