RE: Delete, Move, and Copy for References (Yaron's Issue #9)

What really scares me is a scenario where I have a directory filled with
references but I'm using an RFC 2518 client. If I copy the directory I will
go from a directory that took up a few kilobytes (just to record the
references) to one of any random and potentially huge size. The source
directory ate 30Kb and the destination eats up 6 Gig. I would call that
surprising.

I would also invoke precedent here. In every system I have ever heard of
that supports references (read: links) a COPY always copies the link not the
destination. I would be very hesitant to go against three decades of
accumulated experience without a good reason.

Hence I believe that the default action should be no-passthrough on COPY.

		Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Friday, February 26, 1999 9:52 AM
> To: JSlein@crt.xerox.com
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Delete, Move, and Copy for References (Yaron's Issue #9)
> 
> 
> 
>    From: "Slein, Judith A" <JSlein@crt.xerox.com>
> 
>    <...>
> 
> I agree with everything Judy said up to here, but cut it out 
> for brevity.
> 
>    I don't quite get Geoff's comment that "The client needs 
> to be warned that
>    there really will *not* be a copy made," since I thought 
> the position we
>    were both supporting is that there *will* really be a copy 
> made, both for
>    direct references and for redirect references.
> 
> (This was a comment on invoking a COPY on a redirect reference.)
> 
> For a redirect reference COPY, you could either return the 
> 302 and not do
> anything (letting the client decide whether to do a "no-passthrough
> copy" or copy the target explicitly), or you could return the 302
> *and* actually do a "no-passthrough copy.
> 
> I slightly prefer the former (since normally a "302" means that the
> operation did not happen, right?), but either one is fine with me.
> 
> Cheers,
> Geoff
> 	
> 

Received on Friday, 26 February 1999 14:55:23 UTC