Message-Id: <firstname.lastname@example.org> Date: Wed, 17 May 1995 18:47:38 -0500 To: "Ronald E. Daniel" <email@example.com>, firstname.lastname@example.org, From: email@example.com (Chuck Shotton) Subject: Re: Byte ranges -- formal spec proposal Cc: firstname.lastname@example.org 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 email@example.com http://www.biap.com/ firstname.lastname@example.org "I am NOT here."