Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

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