- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Thu, 24 Oct 2002 10:35:56 +0200
- To: "Lisa Dusseault" <lisa@xythos.com>
- Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
With the current discussion the quota draft will be able to accomodate the Sharemation model as well as a UNIX quota like system. Without adding any complexity. As Eric pointed out, we basically need new definitions of the properties to clarify the semantics. In detail: Am Mittwoch, 23.10.02, um 18:55 Uhr (Europe/Berlin) schrieb Lisa Dusseault: > > Stefan asked (a while ago, sorry to be so late): > >> I can see how this draft is applied to servers like Sharemation >> which have a separate collection hierarchy for each user. > > Sharemation does have a separate collection hierarchy for each user, > but > many other Xythos WebFile Server installations have users share > collections with common names like "sales", "marketing", "hr". The > same > quota system applies to both models, as I hope I'll be able to explain. With that model, you are - in my view - closer to a partition model than what is called quotas in UNIX. If I understand you correctly, sharemation allocates "storage devices" to collection hierarchies and the quota properities report the "space left on device". That is a valid and useful server model. >> I have more trouble applying it to servers where it is common >> that more than one user has write access to collections. Imagine >> that Sharemation has a collection containing all your user >> collections. How would the quota properties appear on that >> collection? > > Quota is applied to a collection, *not* a user, specifically because of > the model where a user doesn't just put documents in their own home > directory. That's explicit in the draft, and it's an important feature > to allow directories to be shared by many users and still have quota > applied. So if a quota of 1000MB is applied to the "/sales/" > collection, the server is free to report that quota, and count space > consumed by resources in the "/sales/" collection in whatever way its > policy decides. That's ok. But there are other servers with real user quotas which need a more flexible definition of the WebDAV quota properties. > >> Where I see a real problem is a server supporting bindings. > > It's specifically left up to the server to figure out how to support > bindings -- it would be impossible for the draft to enforce how to > count > space used, when it's a matter of policy and the interaction of many > potential features. The server may: > - count the space used by a binding as 0 bytes, Then every collection will use 0 bytes. Remember that a collection only holds bindings and nothing else. > > - count the bytes used to store the binding only and not the length of > the resource it points to Then every collection will use just a few bytes (as compared to the amount taken up by the content of all resources). > - divide the size of the target resource among all its bindings, Assume collections /a/b, /a/c, and two bindings to a 1 megabyte resource in /a/b/x and /a/c/x. Then /a/b has bytes-used of 500 KB (same for /a/c), but the client only sees a single 1MB resource in /a/b. Certainly this bytes-used value is not very helpful for the client in order to know the space taken up by the collection. > - count the full size of the target resource against every binding. Assume again the example from above. Now collection /a will report 2 MB as bytes-used. > That's why the draft requires the server to show how space is used -- > it > is not possible for the standard to decide these policy matters. The solution is not to more strictly define bytes-used, but to relax the definition.
Received on Thursday, 24 October 2002 04:36:34 UTC