RE: Removing a resource: A compromise that satisfies?

I agree with Lisa's argument that some servers will want to 
implement quota services.  I just want to keep the quota services
and policies orthogonal from the versioning services.

So how about the following:  I just delete the non-normative
text concerning version deletion from the "how to remove a 
resource from version control" sentence.  This then allows
Lisa's servers to do all the version deletion it wants without
violating anything in the protocol.

(Just goes to show you how much trouble you can get into from
an apparently innocuous "explanation" added to the text of the
protocol ... although this is nothing compared to the "move is a
copy followed by a delete" debacle :-).

Cheers,
Geoff 

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Thursday, June 21, 2001 3:00 PM
To: Jim Whitehead; DeltaV
Subject: RE: Removing a resource: A compromise that satisfies?



Jim said:
> John, Lisa: Let me note that one of the foundations of your argument in
> favor of this capability is an indirect appeal to authority, namely the
> authority of your users/customers. Now, you almost certainly cannot (or
> don't want to) reveal the market research that led to your position. But,
> let me note that when you (or anyone else on the list) make this kind of
> argument, you have a responsibility to ensure that you have, in fact done
> due diligence when reflecting your customer's requirements.

I thought it would be more informative to say that customers wanted it,
rather than to say that Xythos developers thought it would be "a good idea".
An appeal to (customer) authority can be an even stronger argument than
simply personal experience or educated guesses, particularly in this case
where Geoff asked for "use cases".  Who can do a better job of providing use
cases than the customer?  But I accept the due diligence point.

Let me give a use case that's entirely non-opaque, where I can give full
details, and where the due-diligence is automatic.

The site www.sharemation.com uses quotas.  We couldn't afford to run this
free service without quotas, and note that usage numbers count both regular
resources and stored versions.  We also couldn't run this quota-based
service without allowing users to free up their quotas.

So here's the problem scenario on Sharemation: user 'scrooge' turns on
versioning on /~scrooge/foo.txt through the UI or through a hypothetical
DeltaV client.  Then Scrooge uses Web Folders one day to delete a bunch of
stuff.  Web Folders issues a plain DELETE, possibly even issuing DELETE on
entire collections.  Once Web Folders' DELETE is issued, Scrooge would have
no way of finding or cleaning out old versions or version history resources
that still are counted under his quota.  Scrooge's quota would soon be
unusable.

This use case applies to any situation where quotas are needed.  Just a few:
 - A university provides web storage and collaboration space to its students
and professors.  It limits this space (quotas) in order to discourage
improper use.
 - A ISP offers web site hosting to its customers, on a fee-based service.
Customers pay for their quota.
 - XDrive, IDrive etc. - all these free hosting services (some of which
supported Web Folders) restricted quota.

Lisa

Received on Thursday, 21 June 2001 17:22:42 UTC