- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Sat, 22 Mar 1997 01:45:11 PST
- To: Yaron Goland <yarong@microsoft.com>
- CC: w3c-dist-auth@w3.org
> > 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