Re: Progress on AdaOS

[Darren New <dnew@san.rr.com>]

> That would be why objects, processes and RPCs aren't files.

Why not? Again, you're starting with a preconceived notion of "file"
being "an array of bytes", then claiming that the OS should be handling
that as the basic type.

Indeed, RPCs *can* be files. It's called a CGI script. Objects can be
files. It's called an OO Database. Processes can be files. It's called
/proc. Etc.

<TotalRecall> Open your miiiiind.... </TotalRecall> ;-)

For example, on the Amiga OS, files were tasks, as were device drivers,
etc. You could send a message to a file task to read and write portions
of the file into particular buffers, and when the message returned, the
I/O was complete. This allowed you to treat windows as files
(open("con:top/left/width/height/title")) and such. It allowed you to
write phenomes to the voice synthesizer and read lip positions back as
the sound was generated. Cool stuff like that.

Imagine an OS where "files" are actually protected objects, fully typed,
that outlive your program's execution. Directories are simply persistant
protected objects that act as arrays mapping strings to these "files".

> > If there were an AdaOS that didn't allow one to declare a passive
> > partition and say "Hey, this is the data", I'd be disappointed. Why
> > *can't* my "file" have a directed acyclic graph of tagged records
> > holding access values in it?
> 
> An OS could certainly flatten that into a file. It would probably
> take a lot of work to make sure it wasn't an OS/program/libada specific
> file, though.

I don't see any particular need to flatten it as such. Again, you're
trying to map "files" onto "array of bytes in a UNIX-like file system".
That's not the point.

> >> Everything can viewed as raw data.
> >
> > Well, no. Only if you come from the Unix/Windows/CPM world. (Not even
> > there, actually. What's the "raw data" in the superblock? In a
> > directory? In a network-mounted partition?)
> 
> Those aren't files. 

My point is to ask why not. My point is to ask "why limit yourself to
array-of-byte files" and you're answering "because anything else is not
a file." That's not helpful.

> > Those of us who had the privledge of (for example) using ISAM files so
> > you could actually insert a line of text at the beginning of your file
> > without rewriting the whole file can tell you that not everything is raw
> > data. :-)
> 
> When is that much of a win? I don't play around with files large enough
> for this to matter very often.

Put it this way. Let's say files were just numbered in a directory,
rather than having meaningful textual names. When you deleted file 5,
all the files from 6 up to whatever got renumbered. Is it reasonable to
say "why's that a problem? I only work with small directories."

There's a reason folks put names on files, on procedures, on users. The
same reason holds for individual pieces of data in a file. It's a win
whenever you store more than one piece of data in a file, like more than
one line in a text file, more than one user in a password file, etc. And
if you're only storing one atomic piece of data in a file, it's because
you're using the file's name as an index anyway. Have you never written
a program where the name of a file is calculated by the program?
"Image01.jpg", "Image02.jpg", ...?

And yes, it *is* a problem for large files, or folks wouldn't have
invented the DBM stuff to hold /etc/passwd in a hashed file, and they
wouldn't have rewritten directories to no longer be linearly searched. 
Same thing.

If you've never used a system where there are keys on the data records,
you might not understand why it's useful. On the other hand, if you've
only ever used FORTH, where the disk is organized as a numbered array of
sectors, you might not appriciate the charm that having directories and
file names supplies.
 
> > The type for an "Active Server Page" with Ada code embedded in
> > HTML markup under control of CVS?
> 
> text/x-asp.

And how does CVS know it can handle this, and how does the web browser
know it needs to invoke the Ada compiler and not the Java compiler when
rebuilkding this page?
 
> > And how do you determine which
> > programs can read such? :-)
> 
> Any program that can read raw data, or text, or text/ada.
> 
> I'm not sure I understand your point. These are problems for all
> tagged type systems, but you don't seem to want raw data either.

The point is that no passive tagging system is going to be complete
enough that you can specify everything you need to know about the
program in the type tag. Just like every permission system needs
something along the lines of setuid to let you do very specific things
with very specific files that you otherwise couldn't do.

My point is that a persistant data storage system modelled as named
arrays of bytes is just primitive. The addition of type tags tells you
what library to use to understand the interpretation of the untyped
array of bytes, which is just silly when you start trying to use it from
a language like Ada that actually has real types.

> It's always the device drivers. Even in MS/DOS, copy called the OS to
> actually write the file. But if the mac box looks like a directory to
> copy, then copy copies it there, regardless of the underlying mechanism
> to put data in that directory.

Errr... When talking about designing and writing an OS, saying "oh,
don't worry, the device drivers will take care of it" doesn't work.

In any case, a program like "copy" can only copy raw data if the raw
data is primitive. If, for example, you have semantically significant
record boundaries on a tape, and you copy it over TCP, you're going to
lose those boundaries. If you have (say) a database file with pointers
to disk blocks embedded in it, and you copy that file to another place
on the disk, you need to fix those disk block pointers. Etc.
 
> > Anyway, I'd think making a persistant Ada-typed store would be a great
> > file system for an Ada-based OS. Then you could have utilities to copy
> > Text_IO-based files to whatever internal format you wanted (such as
> > "editable text").
> 
> Yuck. Text_IO files should _be_ editable text. Text should be text should
> be text.

Text_IO files aren't editable. There's no way to (say) insert text at
the beginning. There's no way to change text in the middle. Nobody
writes a text editor (at least under an array-of-characters file system)
that doesn't suck the file into a different data structure for editing
and then write it back out. That different data structure is what I'm
talking about. Why not make *that* persistant, and have Text_IO be the
"portability" level. I.e., why insist that "stream" are the "real" data,
and everything else is just this temporary copy inside a program? Why
not let the real data be the one with the pointers and strong types and
such, and only use streams when you want to communicate with a different
OS?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.