- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Fri, 12 Dec 2003 16:16:41 +0100
- To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Cc: w3c-dist-auth@w3.org
Finally someone is paying attention! Am 12.12.2003 um 16:05 schrieb Geoffrey M Clemm: > > I assume in Corollary2, by "all resources", > you mean "all non-collection resources" ? Yes, of course, as usual, you are right. Newly created collections also belong to the same quota space as their parents. BR, Stefan > Cheers, > Geoff > > Stefan wrote on 12/12/2003 04:32:10 AM: > >> >> Chris, >> >> I agree to your analysis that the current definitions lead to >> confusion. The way out >> is to simplify the underlying model. >> >> Definition: a "quota space" is a storage area on the server where >> allocation can >> be restricted. All collections on a server either belong to a >> particular quota space >> or to no quota space at all (in which case storage allocation, if >> possible, in such >> collections cannot be controlled by quotas). >> >> Corollary1: all collections of a particular quota space report the >> same >> values for >> their DAV:quota* properties. >> >> Corollary2: all resources belong to the same quota space as their >> parent collection(s). >> >> Corollary3: all collections which may contain bindings to the same >> resource do >> belong to the same quota space. Collections in different quota spaces >> cannot >> have bindings to the same resource. >> >> With this model, /A and /A/UploadDirectory will either have the same >> DAV:quota* >> values or totally unrelated ones, depending if the two collections >> belong to the >> same or to different quota spaces. Thus the problem of "it does not >> sum >> up" is >> avoided. Also, server side implementation can be much simpler, as the >> hiearchies >> (e.g. bindings) of collections and resources do *not* influence the >> quota values. >> >> //Stefan >> >> Am 11.12.2003 um 19:30 schrieb Chris Sharp: >> >>> 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 Friday, 12 December 2003 10:19:47 UTC