Re: Comments on Byte range draft

Chuck Shotton writes:
 > 
 > Perhaps you should take YOUR blinders off and realize that HTTP transmitted
 > content is not a simply byte stream as far as the server is concerned. The
 > data objects are more complex than a simply binary file on disk, the
 > operations and translations performed on them are more involved than
 > blindly reading content off the disk and squirting it onto the net, and
 > that server implementors have a lot more to be concerned with than
 > implementing an inefficient, partial solution to the problem you describe.
 > 

If a server claims to support byte ranges, then it always has the
option of implementing them trivially (but expensively) by simply
editing its own output, either on the fly or out of a server-side
cache.  If it has a cleverer algorithm for reverse-mapping from byte
indexes to the position in its own internal representation, then so
much the better, but that is in the realm of optimization.  There
is always a way to do this, and it is usually going to be more
efficient even to do the naive thing of generating the whole document as
it will be transmitted, and throwing away all but a requested range of
bytes, than it would be to generate the whole thing and then transmit
the whole thing.   Now, whether its a good idea is another question.

	...

 > And trying to anticipate every server-side representation scheme by
 > generalizing everything to a byte stream takes us back to 1975 when Xmodem
 > showed up on the scene.

	...

Despite the fact that it's 1995, what goes over the net is still a
byte stream.  This isn't about internal representations, and servers
don't have to implement this.  (They better not have to...)


Shel Kaphan

Received on Sunday, 12 November 1995 14:59:42 UTC