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

The new draft of quota is out, but I never responded directly to these
comments (sorry).

> -----Original Message-----
> From: erk@unx51.staff.flyingcroc.net
> [mailto:erk@unx51.staff.flyingcroc.net] On Behalf Of Erik Seaberg
> Sent: Thursday, January 10, 2002 5:52 PM
> To: w3c-dist-auth@w3c.org
> Cc: Lisa Dusseault
> Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt
> 
> A client that wants to know how much storage is actually available in
> a collection has to PROPFIND each parent up to "/" looking for the
> minimum (quota-bytes - space-used-bytes) value.  That number should be
> a live property, since any server enforcing quotas must be able to
> produce it fairly efficiently.

That's true, but even knowing that the client can't necessary assure
their request will succeed.  I suspect that if the client just PROPFINDs
the current collection and subtracts space-used-bytes from quota-bytes,
the client will get an answer that works just as well 99% of the time.
If implementation experience suggests otherwise, I'd support this live
property as well.

> It's natural to want to handle this through quotactl(2) on Unix, but
> the draft says {DAV:}space-used-bytes "MUST include child collections
> and all resources inside those child collections" without regard for
> who created them.  Is the intent that all users MUST (or SHOULD) see
> identical {DAV:}quota-bytes and {DAV:}space-used-bytes values, or may
> an admin reveal quotas they've assigned to particular users?

It didn't say that it is without regard for who created them.  The
server is free to count any resource as 0 bytes against space-used for
all kinds of reasons (e.g. the resource is a binding).  The sentence was
intended to ensure that quota was understood to be recursive by clients
and servers.  Do you have better wording?

> Should a client be able to atomically reserve some of a collection's
> storage so expensive requests don't have to race with others to claim
> the last bytes?  It could be a header like
> 
> 	Expect: 100-continue, reserve; content-length="999999"
> 
> in a large PUT for example, or a live property on a collection
> allowing a reservation for several smaller resources or properties.
> 
In theory this would work already.  However I suspect servers
implementation of the Expect header is poor in reality.

Lisa

Received on Wednesday, 23 October 2002 12:48:30 UTC