RE: Removing a resource: A compromise that satisfies?

Works for me.

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff
> Sent: Thursday, June 21, 2001 2:22 PM
> To: DeltaV
> Subject: 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 18:32:16 UTC