From: Keith Moore (moore@cs.utk.edu)
Date: 03/20/97-01:29:38 PM Z
Message-Id: <199703201929.OAA24752@ig.cs.utk.edu> From: Keith Moore <moore@cs.utk.edu> Subject: Re: Structured files Date: Thu, 20 Mar 1997 14:29:38 -0500 > At 10:53 PM 3/19/97 -0500, Keith Moore wrote: > >> A structured file > >> is a file, the access to whose contents is meaningful only through the > >> execution of code that is intimately related to the file or through > >> code that can be created that understands its content. > > >Sounds like a disaster to me. Now you need different methods to > >access the file depending on what you want to do with it (do you want > >to read records from the file? copy it? dump it? compress it?). This > >would not only be very system dependent (and thus has no business > >being in a standard), it would also break every application I use. > > Well, this happens on a daily basis on the Internet and it is not > yet a disaster. What happens on the Internet is mostly transparent open/close/read/write file access on byte streams, and I agree that it works pretty well. I don't want to mess it up by adding lots of new special-purpose functionality. > By having NFS V4 standardize this whole process, we > would be averting a disaster. The intention here is to solve an > existing problem.(which is very likely to get more complex) > Have you not had to download Acrobat or something else to "access" a file? > Or Real Audio? Sure, but trying to put application level functionality into a file access protocol is just plain wrong. Everything we've learned since the 1960s says that you want to move the complexity away from the common infrastructure (be it the operating system or the network) and toward the few applications that actually need it (and meanwhile, encourage them to get by with less). The core needs to be simple and flexible and not get in the way. A file access protocol is part of the core, something that gets used by lots of applications for various purposes. We don't want application-specific functionality in that core. > >> Today we live in a world, where there are all sorts of file formats and > >> structured files, from html to audio to video etc. Every day new formats > >> get invented, and there seems to be no end in sight. Without a generalized > >> way of knowing how to "access" these files things, we would not be solving > >> the central problem of todays file access. > > >Fortunately, we have a generalized way to access these things: > >open/close/read/write/seek on octet-streams. > > It seems to be inadequate in the internetworked environment. To > solve the problem of system dependent code we have come up with > a whole new variety of file formats and even virtual machines. > We need a way of better specifying the contents of files and how > to access them. Nope.. you haven't given a single reason why this should be the case. And every bit of my experience with MCP and VMS -- systems that support incredibly baroque file structures and access methods -- tells me that this approach is misguided. All of my experience with proprietary data formats tells me that they are also disasters; I'm sick of being handed perfectly ordinary text in formats that I cannot read. Fortunately, standards-based formats tend to replace them in the long-term. So no, support for these in NFSv4 is neither necessary nor desirable... At worst there should be no more than a frob that says "here is the MIME type for this file" or maybe one that says "if you want to find other methods for accessing this file beyond open/close/read/write, look here" Keith
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:34 AM Z CST