Re: Partial Puts

> 
> As for your observation on range lengths. If I understand your point
> then you would want to see the range header specify the range to be
> inserted into and then have the body placed in that range. If the range
> to be inserted into is say, 15-20 and the body is 10 bytes long, then
> the first 5 bytes of the range will be overwritten and the remaining 5
> bytes of the request entity will be inserted. This is a nice feature but
> it complicates the implementation of the server. Keeping the operations
> as insert or overwrite not only makes for simpler code, it also makes it
> easier to leverage services already present in OS's.

You're claiming that implementing two separate methods is simpler than
implementing one method with two parts, one for overwriting the first 
part of the overlap and the second for inserting any remaining content
or deleting any of the replaced range not overwritten?

I basically don't believe your assertions about simpler code
and leveraging services in the OS. Range replacement is the standard
programming language construct for doing this, and I don't see any
reason why WEBDAV should be different.

> The clean is the RANGE method. I think everyone can agree on that much.

Well, I think cleanliness is clearly debatable, but there are probably
several "clean" interfaces.

> The problem is, its performance is no where near good enough for anyone
> who needs to sell a system to implement. So the question we need to ask
> ourselves is - Are we willing to sacrifice some cleanliness for
> interoperability? 

Wait, you're sacrificing cleanliness AND interoperability for
performance
of a single implementation.

> If everyone is going to implement something like a
> range header and if they all do it separately and thus differently, have
> we aided the cause of interoperability?

This is nonsense. If RANGE has well-defined semantics, it will be
interoperable.


> I am not saying that we should
> sacrifice good design on the alter of performance.

Yes you are. And it's a false god.

> I am saying that
> sometimes there are close calls when the clean solution has not so great
> performance, and the close to clean solution has excellent performance.
> I believe this is one of those times.

I think this is a dubious argument. You have a particular implementation
and a close call ship date, and made a choice. It's not clear that the
things that led to your performance problems are persistent, would be
true for any other back-end, method, etc.

Received on Saturday, 22 March 1997 04:59:29 UTC