RE: Removing a resource: A compromise that satisfies?

Which brings me back to the point I made a long time ago: Why can't the
default for dump clients be "zap the version history"?

We already have the server option NOT to zap history if the server
doesn't want to do so.  I always thought that a default of 'ZAP it'
unless instructed otherwise solved both problems.

Earlier, Geoff said:
First, I'd like to emphasize that I agree with the following 
statements:
- the protocol should support the explicit deletion of versions
(although a server may refuse the deletion request)
- servers will provide some mechanism for reclaiming space (possibly
involving auto-archiving, and maybe even auto-deletion).
================= SO ==========================
Why isn't "servers will provide some mechanism for reclaiming space
...maybe even auto-deletion"

Solved by having the server zap the version history on DELETE?  By not
having a client tell the server what it wants to happen, you make it
impossible to separate an uninformed client from an informed client.

If the spec said an implementation MAY zap it unless directed not to do
so, a smart DeltaV client knows what to do.  If it wants the version
history destroyed, zap the VHR then the VCR.  If it doesn't, say so on
the DELETE.  Then it knows what will happen, consistently.  So the
client gets its consistency and the server dealing with older clients
gets its flexibility in the presence of features like quota limitations.

Meanwhile, a server that supports WORKSPACES and doesn't consider the
reclimation of space orphaned by dump clients an issue can choose a
different default.  The default doesn't effect smart clients, only dumb
ones.  The dumb ones can't be confused, since they don't know they are
using a DeltaV server anyway.

Why isn't that better than having a server implement "auto-deletion"
without any ability to effect the process?

Peace


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Lisa 
> Dusseault
> Sent: Thursday, June 21, 2001 12: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:14:06 UTC