Re: Comments on Byte range draft

On Mon, 13 Nov 1995, Chuck Shotton wrote:
> I'd like to see a well-reasoned discussion on your
> part about the valid concerns that server implementors have regarding the
> need to re-render entire documents to serve you a byte range for low-value
> reasons like interrupted file transfers, etc. and why you think it is OK to
> ignore these concerns.

Personally, I don't consider anything that appears to give the user poor 
performance and wastes network bandwidth to be a "low-value reason".  
There *are* servers out there in the Net today that do send back just a 
stream of bytes from a file to the user's browser _and_ there *are* 
interrupted transfers over slow links.  The ability for a client do look 
at its local disc cache and say "Oops, I only got the first 500K of this 
1M file last time, I'll try a byte-range for the last 500K" is useful.  
If your server doesn't support that feature then fine, the user is no 
worse off than he is now.  If you do support that feature he gets his GIF 
faster and uses less bandwidth.  Surely that's good news for everyone?

> This is a trivial academic point. Please stop fixating on it. Of course all
> data flows across a HTTP connection as a linear stream of bytes. That's the
> whole legacy of a Von Neumann architecture. Now that we are past Data Comm
> 101, let's talk about whether or not it makes sense to force byte stream
> manipulations on applications that deal with pages, images, database
> records, complicated relational objects, real-time generated displays, etc.

Hey, nobody's forcing you to use them in your server - if you don't 
support byte ranges (either at all or for a particular class of objects) 
then you can send back a full response just as you do now.  No worries.  
A byte-range aware browser (which is the only sort that could make the 
request) would be able to spot that you've sent the whole thing and act 
accordingly.

> You seem to want to trivialize the function of the Web and associated
> applications to the lowest common denominator of moving the contents of a
> file from point A to point B, a byte at a time. This is an absurdly
> low-level of abstraction. It's like talking about building a house by
> aligning protein and sugar molecules so that they form 2x4s, lining up iron
> atoms into nails, etc.

There's a lot of subatomic home construction going on in the Internet at 
the moment then... :-)

> Clients have no business
> knowing about the internal representation of items stored at a given URL
> and allowing them to ask for specific chunks out of a file with something
> as coarse as a byte range violates the entire principle of a URL.

Ah, there's a difference between having a opaque string in the *URL* that 
is passed to the server that the client shouldn't interpret and having 
the client be able to know about the internal representation of the 
*objects* that the URL points to.

> Specifically, a URL is supposed to be a client-opaque method for requesting
> information from a server. URLs are given to clients by servers or by
> humans. The path information contained in a URL is supposed to be the
> private domain of the server. Allowing a client to generate or manipulate
> this portion of a URL outside the bounds of the current hierarchy
> manipulations allowed in the URL standard is WRONG.

If the byte range is specified in the URL then one must assume that a 
human or server has given it to the client (and that it's opaque to the 
client).  If the client is generating a Byte-Range: type header in its 
HTTP transaction becaused it received a partial object then it isn't 
looking in the opaque part of the URL either - its looking in its local 
object cache.

> As desirable as it may seem, there are serious integrity and consistency
> problems that this opens up for the Web at large if this becomes an
> integral part of the URL standard. On the otherhand, if it is a convention
> that is adopted through the simple addition of a conforming CGI, the server
> retains the ability to tell the client how to access information it
> controls, the client gains the ability to access portions of documents, and
> the overall model that governs how URLs are manipulated is maintained.

Er, by using a CGI script, isn't the client effectively mutilating the 
URL by changing its opaque part and doing exactly what you've been saying 
not to do?

> Well, technically it's a bit stream. But even so, why are we continuing to
> twaddle about in the low level bits and bytes of this problem space when we
> could be building easier to use application level standards?

Because if you don't consider whats floating along the wires you end up 
in OSI land.

> If you are
> intent on forcing server implementors to pre-render all content so you can
> be served a "byte stream" of particular offset and length, why not ask for
> something that makes a little more sense in the context of the WWW, like
> pages, images, records, etc.?

Nobody is forcing the server implementors to do this (other than if all
their users cry out for it to be supported but that's normal market forces
at work on the Net).  If they all think its a crappy thing to do, then
they can just not support it and everything will carry on as it does at
the moment.  But if they *do* choose to support it, at least there'll be a
standard way of doing it.  Ditto for the client writers.

> And what's more, why not allow servers to
> tell the client FIRST what representation is has chosen for partial
> document transfers (byte, page, record, etc.) and tell the client HOW to
> make the request for these document portions? This last point is, I think,
> the most important one to consider.

Didn't we go through the byte/page/record options when byte-ranges were 
first proposed many millenium ago and have people raise similar 
ideological objects to the others as to byte ranges?  Lets go with the 
easy one (byte ranges first) and then those of you how are more 
structured than the rest of us can propose extensions for your favourite 
objects.

> Aw heck, let's just replace URLs with SQL queries and be done with it.
> That's where this whole discussion is heading anyway.

Now there's an idea... :-)

Jon

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer
Studies, Loughborough University of Technology, Leics., ENGLAND.  LE11 3TU.
* I've found I now dream in Perl.  More worryingly, I enjoy those dreams. *

Received on Monday, 13 November 1995 12:15:10 UTC