- From: Eric Sedlar <eric.sedlar@oracle.com>
- Date: Wed, 23 Oct 2002 15:01:08 -0700
- To: "Julian Reschke" <julian.reschke@gmx.de>, "Lisa Dusseault" <lisa@xythos.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
> > > > All I want is for interoperable clients to have two properties: > > > > * how much junk can I store in this collection > > Yes. > > > * how much junk have I already stored in this collection (and thus could > be > > used if I delete stuff, potentially) > > That's hard to answer in the presence of bindings. It's certainly not a > property of a collection. > That's why I used the word "potentially". It's just a way of giving the user some indication of how much space could be usable in this collection in the best case (where any other space-occupying resources have been deleted). Certainly, if I have one collection mapping to D: and another mapping to E: on a Windows machine, I would have different "used" quotas for different collections. I don't see why it's not a collection property. > > I'm happy with the properties--I just think we need to change the text to > > indicate that the quota only applies to the currently authenticated HTTP > > user--an interoperable client cannot assume that the quota will be the > same > > if authenticated as somebody else. I don't think we need an ability to > find > > out how much quota other people have. > > I think that if the proposal is supposed to be generic enough it shouldn't > even try to define how quotas work, how nested collections work and so on. > Just define one or two live properties (or possible one report) that gives a > client the required information. I agree that there isn't really a need to define how nested collections work. If I have another partition mounted beneath a parent collection, the collection will have no idea how much space is available in that particular child collection. All we need is the two live properties, and language that indicates that the only thing quotas control is how much new content you can create (either in a resource, or by creating new subcollections). --Eric
Received on Wednesday, 23 October 2002 17:59:36 UTC