[Oberon] Re: file system (Ghost in the Machine)

[Antony Tersol]

I didn't think Aubrey was being patronizing; however, the statement:

> I expected that anyone who has used PCs for more than a few years
> is familiar with the need(s) to organize groups of files and not
> mix them at random into a single directory.  I see this was an
> error on my part.  I retract the word "patronizing".

seems to indicate a misunderstanding.  My interpretation of Aubrey's
question was that he was attempting to seperate the low-level
organization of the files from the method of access.  If a file system
has one access method that is congruent to the standard PC hierarchical
access, the different underlying structure might allow other, more
powerful and flexible access methods.   

> If you do NOT maintain low-level compatibility your OS will never
> gain broad support, will be forgotten, and of no consequence.

PCs also used to restrict names to the 8.3 convention.  Must an
acceptable Oberon OS be forever slave to PC strictures? 

> Low level routines should be modular/replaceable when the tides
> of change are upon us.

If only MS maintained such laudable practices.  Are the tides you speak
of those created by the gravitational forces of the moon-sun of MS?

Whatever the filesystem, it serves to "organize groups of files and not
mix them at random" on a physical hard-drive.  The files in a
subdirectory are associated only by virtue of entries in a directory
structure. The MS filesystem is a hierarchical database.  And my
experience with Windows shows me that the existing "Low level access to
the file system imposes" "speed penalties" and "imposes restrictions
further along the way that" "limit options available to application
programmers who want to implement a different type of access not
compatible with" Microsoft "routines".

> "Database" and "power" seldom belong in the same sentence or even
> the same paragraph.

Databases would not enjoy their success if they did not offer
significant benefits to the user.  Relational and object databases are
worthy of consideration as alternatives to the traditional hierarchical
filesystem.  Other structuring methods offer the possibility of unifying
the access to information across the local-machine/network/internet
boundaries.  

Rather then a priori deciding on a particular filesystem (or any other
OS component), it might be more beneficial to focus on "needs" and
"wishes".  In other words, instead of saying "I must have a files system
with nestable subdirectories", one might define the ways in which one
wishes to view and access file collections.  Rather then restricting all
users to the lowest common denominator, a different, more powerful file
system might be made capable of accessing legacy systems, while offering
enhanced capabilities in its native structure.  (In other words, one
might choose the "Standard MS View" as one's default, and see nested
folders with files inside, while someone else might choose differently).

BTW, I have over 20 years working with various computer systems (not
just PCs - I assume you are conforming to the convention that PCs refer
to Intel-compatible chipsets with MS OSs).  






> Message: 2
> To: "OBERON SYSTEM 3" <oberon at inf.ethz.ch>
> From: "Ghost in the Machine" <cangelich at famvid.com>
> Date: (No, or invalid, date.)
> Subject: [Oberon] Re: file system
> Reply-To: oberon at inf.ethz.ch
> 
> Message: 1
> From: mcintosh at vima.austin.tx.us
> Date: Fri, 19 Jul 2002 08:01:55 -0500 (CDT)
> To: oberon at inf.ethz.ch
> Subject: [Oberon] Re: Commercializing Oberon: User Needs, subdirectories
> Reply-To: oberon at inf.ethz.ch
> 
> --8<--cut
> 
> > For reasons too bizaare to be sensible, I have thought about getting
> > a second Ph.D., this time in computer science.
> 
> I don't have a Ph.D.  I have over 20 years working with various PCs.
> 
> --8<--cut
> 
> > If, however, I require low level compatibility with a legacy data
> > structure invented when portable media was 8" wide and held 160 Kb of
> > data, my options for innovation are minimal.
> 
> If you do NOT maintain low-level compatibility your OS will never
> gain broad support, will be forgotten, and of no consequence.
> Low level routines should be modular/replaceable when the tides
> of change are upon us.
> 
> No one I know is looking for yet another foreign file system or
> partition type to foul up their existing installed (working)
> software.
> 
> --8<--cut
> 
> > From this perspective, I view my original question as deliberate,
> > clear, important and appropriate to this discussion.
> 
> I expected that anyone who has used PCs for more than a few years
> is familiar with the need(s) to organize groups of files and not
> mix them at random into a single directory.  I see this was an
> error on my part.  I retract the word "patronizing".
> 
> > Based on the work that I did in making the ISO_9660 compatible file
> > system, I envision that a change to the file name scanner to include
> > the "/" character in a file name would allow the command in the
> > example to execute, and to give the results described, on a "flat"
> > file system.  Moreover, it would give additional power.
> 
> "Database" and "power" seldom belong in the same sentence or even
> the same paragraph.
> 
> > I have some objections to this solution.  You may also object to this
> > solution.
> 
> > Can you explain why?
> 
> Low level access to the file system imposes fewer speed penalties
> and any embedded `database' would impose restrictions further
> along the way that would limit options available to application
> programmers who want to implement a different type of access not
> compatible with `database' routines.
> 
> Unless your, in your vocabulary, database read in blocks of code
> then we are diametrically opposed on this.
> 
> Charles.Angelich
> 
> From: "Ghost in the Machine" <cangelich at famvid.com>
> | > Let me explore the following user interface scenario.
> | >
> | > 1.  A command of the nature
> | >         System.Directories eMail/Y02/July/*
> | > produces list of file names that the user named and saved from email
> | > received in July 2002.
> | >
> | > Is this the sort of thing you are missing?
> |=20
> | Don't be patronizing.
> |=20
> | I want to be able to separate sets of files into subdirectories
> | not clump them all together in one huge directory.  MSDOS
> | v2.1 had subdirectories - did  you notice that?
> |=20
> | =20
> 
> --__--__--
>