From: Anton Aylward (anton_at_the-wire.com)
Date: Mon May 10 2004 - 13:49:30 PDT
On Mon, 2004-05-10 at 15:46, Richard G. DAVIS wrote:
> However, classical files are not structured by rules embedded in the
> operating system. A Windows file can be structured anyway the designer of
> applications that will use the file wants to set up these files.
Blech. Check your history.
Up until the days of UNIX, files were structured, and the structure WAS
manged by the OS. UNIX was revolutionary in that it introduced the idea
of a file as a simple array of bytes whose meaning and structure was
interpreted and managed by the application.
Even as late as VMS (early 1980s) the 'classical' OSs worked that way.
Dave Cutler had long arguments in the technical press and at conferences
with Bill Joy over which was faster on the VAX, Cutler's hand optimized
assembly code and umpteen different file formats used by VMS or Joy's
compiled C and the 'array of bytes' file system.
One can claim that Joy "won" because Cutler swore he would never write
another OS in assembler and when he came to write the Windows (NT) OS
he used C and as Richard points out Windows also uses the 'array of
bytes' file format now.
> The Newton Soup is not a new concept, nor is it specifically appropriate for
> the Newton alone. Instead, the soup concept is a hugely powerful
> "long-term" "system-storage" approach to information storage that is not
> widely recognized for its merits over classical, directory oriented system
> storage. One noteworthy basis for resistance from the technical community
> to the Newton technology, I believe, arises from the general lack of
> understanding of the 'soup' approach.
As for the idea of the 'hierarchical directory' -- that came from UNIX
as well. I recall in the mid 70s, arguing with my cousin who was doing
CS at Bangor; I was advocating the UNIX hierarchical file system as a
natural, anthropomorphic approach since humans find a hierarchy quite
natural, he was advocating the 'dataset' approach of IBM where there is
the one 'file' and its internal structure is partitioned in a manner
that might appear similar in logic (though not implementation) to a
'soup' since the dataset is a single logical entity no matter what you
do with the components that you create to make it up.
So, there was at the time of UNIX, call it the 60s and 70s, a strong
resistance to the possibility of introducing a directory oriented
design.
> There is a strong resistance to the possibility of setting aside the
> directory oriented design for long-term system storage in favor of thinking
> along the lines of 'soups', or whatever else you might call these
> alternatives. This is a most unfortunate impediment to progress in
> information systems design.
One might also consider what many people end up doing with Lotus Notes.
I see them using the Notes database as a filing 'cabinet'.
> ========
> The power here is in the fact that the program can 'assign' other values to
> the NAME "ALPHA" in the future and change how the program behaves, BUT the
> program itself does not have to change.
That too is not always true. For example in VMS some name binding was
done at the system level.
> Now, in classical programs using classical directory storage, these
> assignments of NAMES to DATA do not PERSIST after the program that initially
> makes the assignments has been terminated.
In modern programs we also have the - unfortunate - ability to not use
DNS to bind names to addresses, that is some people hard code IP
addresses into programs.
> In Windows, UNIX and MacOS, the
> associations of names with data do not persist in long-term system storage.
> Every time a Windows program wants to print out the data value of the NAME
> "ALPHA", the program has to resurrect the whole process of assignment of the
> value "NEWTON" to the NAME "ALPHA".
It would be more correct to say that name has to be resolved to an
address -- that of the file-data, or the name resolved to an IP address.
The association of the names to the addresses, be it as a directory
under UNIX or a FAT table entry under DOS, ** IS ** part of that long
term storage, since the directory itself and the directory structure is
a 'file'. In the case of UNIX and its derivatives the root of the file
hierarchy, I-node #1, is hard coded into the OS ---> "1". You can grep
the binary for it.
> IN CONTRAST, IN THE NEWTON, assignments of data values to names, such as
> binding the data value "NEWTON" to the NAME "ALPHA" is preserved in the
> Newton Soup.
Just like the directory to i-node mappings are stored in the UNIX file
system so they persist between reboots.
> Thus, in the Newton Soup, storage is NAMED storage, and those
> binding of names with data values are persistent.
See above.
> The association of the
> value "NEWTON" with the NAME "ALPHA" is preserved in the soup indefinitely.
See above.
It doesn't matter if your long term storage is rotating disk, NVRAM or
what.
> This is the "really big deal" about the Newton soup--it provides PERSISTENT,
> NAMED system storage, something not found in most other modern information
> systems.
Perhaps you want to explain this differently.
In a way that us old timers who were around long before UNIX and know
about other 'classical' file systems can see the point you're making.
Something, perhaps, that acknowledges such storage media as punched
cards and mercury delay lines.
-- Anton Aylward <anton_at_the-wire.com> -- This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries Official Newton FAQ: http://www.chuma.org/newton/faq/ WikiWikiNewt for all kinds of articles: http://tools.unna.org/wikiwikinewt/
This archive was generated by hypermail 2.1.5 : Mon May 10 2004 - 15:30:00 PDT