| From: | Ed Dana |
| Date: | 9 Sep 2000 at 02:23:47 |
| Subject: | Re: AMIOPEN: A few questions... |
Aaron Ruscetta wrote:
> On Thu, 7 Sep 2000, Ed Dana wrote:
>
> > They need something akin to the Classic Amiga "assign" command.
> > Leaving this out would be tragic, IMHO.
>
> Amiga's ASSIGN is a great mechanism, no doubt about it. I miss it a
> lot on every other system I have to use.
>
> Though in following some File System threads on the PHX list and
> giving a lot of thought to the problems, two other paths <PI> appear
> as possibilities, especially since the stated etherial AMI goal is to
> do away with the "file" concept all together.
>
Personally, I think this is nonsense. :) Call it "a file", call it "an
object", call it "fred", users are still going to think of their data as
files and still want to be able to find them. I read some of Amiga's hype
on that subject, and that's exactly what it is: hype. :)
> One, as suggested by some on PHX, is to make every file a true OBJECT,
> where all locality, datatyping, conversion, etc. is handled by a
> services registry and the object itself.
>
This, of course, is what I hope they do. But users will still call them
files, just like people still call a paper copy a "Xerox" today. :) But
even if they do, there will still be flat files. These aren't going
anywhere, they're just too valuable for storing information in a simple,
pragmatic way to disappear.
> My own musings on the discussion led me to another idea (probably an
> old one, maybe an overly simple one, and definitely hypothetical, but
> here it is anyway):
>
> A lot of the shortcomings in the file system and network access
> paradigms I've seen come from the simple fact that the data's
> Physical Locality is basically locked into being the Top level.
> ( eg. Amiga's ASSIGN command is such a powerful tool because it lets
> you re-define and extend any Physical Directory or Device on the
> system as the Top Level of a file's location reference).
>
> So what if we had a file system where the Physical Access layer (and
> related considerations like available storage space) were moved to the
> position of being a File Attribute??
>
> In brief, all available data Packages (via net links, stored files,
> etc.) would be in a database or registry maintained by the File
> System. In this DB/list, "DEVICE" is an attribute of every Package.
> This attribute defines the Top Level location reference for any
> Package access by the system.
>
> With such a File system, when one did something like...
>
> "LIST pix/ FILES"
>
> ...instead of seeing just the data available in one physical
> location, you would see the files in every location where "pix/" was a
> directory of a Package's top level. (!) A user could easily list all
> the pictures
>
> Limiting the search would be as simple as using the DEVICE attribute
> in the same way you can use path and pattern matching with present
> file systems. If one only wanted to see the files in the 'pix/'
> directory of the HD0: device, perhaps the command line request would
> look somethin like:
>
> "LIST pix/:HD0 FILES"
>
> ...anyway, I think that communicates the idea and hopefully gave a
> little fuel for thought.
>
> Of course, most of this would be equally realized with proper
> implementation of an OBJECT based file system. I just thought the idea
> worth sharing and thinking about here. Also, since almost none of the
> implementation details for AmiVerse are available, it may be that some
> elements are still in flux and worth discussing.
What your describing is a relational file system. This has already been
done. :) Oracle (my bread and butter) was pushing using their database as
a file system. This would allow users to do some of the things you
describe (most likely through the use of SQL). So far, though, nobody
(that I'm aware of) has bought into it.
Object databases, BTW, are not all that different from Relational
databases, so an Object file system will not be all that different from a
Relational file system.
That being said, however, the Assign command still needs to be there.
Whether the file system is Hierarchical, Relational or Object, a single
instance of an Object will still reside in a single place. I.e.
Drive1:Applications\Graphics\Renderer\LightWave\<executable>. It would go
beyond stupid to ignore the benefits of the Assign command. Whether that
instance changes (you move it to a new drive or directory) or you have
multiple instances (maintaining older versions for compatibility) it is
simply *too* valuable not to be able to tell the system to "look here" for
the program you want to use. Such is the power of that little command.
If Amiga Inc. has a better way, I'd like to hear it, of course. :)
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html