Re: Byte ranges -- formal spec proposal

At 4:59 PM 5/17/95, Ronald E. Daniel wrote:
>Byteranges are pretty nice since they are broadly applicable,
>but I am not sure what it means to ask for a byterange of
>a database. This problem is even more acute when we get into
>parameters such as "paragraph", "row/col", "stanza", etc.
>How are we to indicate when a parameter is inappropriate for
>a URL, such as paragraph for an image? Usually row/col
>will be inappropriate for HTML files, but if we have previously
>selected a table then it is the natural way to get a table
>element. How do we do that?

Worrying about stuff like this is WAY outside the bounds of asking a server
to send a particular range of bytes out of a data file. Remember, servers
typically are ignorant of the semantics of the data they serve. You are
running the discussion off into an area that is NOT a Good Thing (tm) for
server authors. Worrying about things like what a byte range means is
strictly for the client and the viewer app.

>If we do not develop a uniform architecture for fragment
>identification, we are going to have a slew of partial solutions before
>we wise up and develop a uniform treatment.

There are plenty of OO standards for defining the semantics of all the
different data examples you cite. However, they aren't really within the
scope of what servers (or WWW clients for that matter) need to worry about.
It really is an issue of a remote app wanting random access to the server's
file system and nothing more. Let the remote app worry about the semantics
of the data it is asking for and we'll all sleep a lot easier.

The Adobe people have done a LOT of work in this area already and as
complicated as Acrobat's document store is, they seem to be able to cope
with having the viewer/client ask for simple byte ranges. You have to make
an awfully good case for why simple byte range requests need to be
perverted into full-blown "fragment requests". There is a need for byte
range specs NOW. There is no apparent need for fragment requests,
especially since there is no common object model in place for
HTTP-delivered documents.

HOWEVER, things are going to be a LOT more complicated when new O/S
implementations start showing up with multi-fork files. The Mac O/S already
suffers under the Unix-driven limitations of HTTP because there is no
explicit support for the 2-part files in the Mac O/S. This will only get
worse because there are many new file systems in work that support the
concept of an unlimited number of data forks associated with a single
"file". How do byte range specifications work for this case?


-----------------------------------------------------------------------
Chuck Shotton
cshotton@biap.com                                  http://www.biap.com/
cshotton@oac.hsc.uth.tmc.edu                           "I am NOT here."

Received on Wednesday, 17 May 1995 18:04:38 UTC