Re: Structured files

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: werme@zk3.dec.com
Date: 03/20/97-02:21:40 PM Z


From: werme@zk3.dec.com
Message-Id: <9703202021.AA10256@wasted.zk3.dec.com>
Subject: Re: Structured files 
Date: Thu, 20 Mar 97 15:21:40 -0500

   > 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.

Here's a scary thought - take that diary app, and put it on VMS.  You'll
want variable length records for the text portions, fixed length for the
bitmap portions, and lord-knows what for the dates.

If we're going to build in file data structures for the file's contents, it
seems only fair that we extend that to the OS's underlying file system
data structures too.  (Of course, in this case, I imagine whoever ported
the diary app to VMS would say, "Wow, look at all these record formats!
I'll just use the one most like the byte stream I used on good ol' MS-DOS."

  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.

Heck, I'm sick of yet-another-PC-program that stores configuration and
other data in binary files so that I can't easily write awk scripts
or whatever to create personalized tools.

	-Ric Werme


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:34 AM Z CST