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

One more point on the "space of a COPY" issue.

When a downlevel client asks "what is the size of this GIF resource",
and the answer came back "20 bytes" (because the resource was actually
a direct reference to a GIF resource and the server is just telling
it how much space the reference takes), that downlevel client will
probably be a bit surprised when it allocates a read-buffer based on
this size answer, and then tries to GET that GIF file into a 20
byte buffer.

Similarly, if that client asks "how big is this collection of GIF
resources", and the answer comes back "200 bytes" (because it is just
10 references to GIF resources), the allocation of a 200 byte buffer
to store that GIF collection won't work much better.

So I will argue that a "size" query, like all other queries in the
context of references, should take a NO-PASSTHROUGH header (so an
uplevel client can ask for both flavors of "size"), but that the
default "size" query should be passed through to the targets, and then
a downlevel client would be surprised if Yaron's copy did not take 6 gig!

Cheers,
Geoff

> From: Yaron Goland <yarong@microsoft.com>
> 
> 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.

Received on Saturday, 27 February 1999 11:02:46 UTC