files, printers, etc. [Re: The feel of a LispM/List of running machines]

[Chris Bitmead uid(x22068)]

>This also directly benifits the application users, since they can refer
> to files in whatever normal manner that they already know.  
>The file server host name is specified at the beginning of the 
>file name, like these examples:
>
>  "AI:STAN.K;LINES >"
>  "<PDL.SRC>ZORK.MID.3"
>  "Secrets:>udd>ManOfMystery>Deep>Dark>crpyto>nuke>plans"
>  "Quabbin.SCRC.Symbolics.COM:>CStacy>hacks>demo.lisp.newest"
>  "BARNEY:\FROGS\EYES.TXT"
>  "prep:/usr/local/lib/etc/etc/etc/biteme.arf"

IMHO this is a bad idea. One of the things that Unix gets right over
the NT/DOS world is avoiding this machine:file or a:file syntax.

Files should be located where they logically belong. If application
FooBar happens to be on machine "tiger", I shouldn't have to know
that. Besides, it might be moved onto machine "lion" one day.

I, as a dumb user just want to type ">applications>FooBar" and have it
found.

>In addition to the usual TCP (and RPC) based file access protocols, 
>the Lisp Machine also has its own proprietary protocol called NFILE.
>Think of it as sort of like NFS, except there's no mounting, configuring,
>pretending that file names all look like UNIX, getting hung up, locking
>problems, or anything else.  

You need some security, and you need interoperability, and you need
caching, and you need multi-user. That means you need mounting,
configuring and pretending and locking.

Unix isn't the way it is just through bloody-mindedness.

>It just works perfectly, all the time.

:-)

>First, there are its own native file systems.  The one intended for use by
>applications wanting a conventional file system is called LMFS.  Is had long
>case-preserving file names with seperate type and version (generation)
>fields, also arbitrary user-definable property lists on files, hierarchical
>directory structure, ACLs, guaranteed un-delete, and various date and flag
>fields (dont-delete, backed-up, etc.), and wildcard operations.  

I disagree with all of this. The above features are not powerful
enough for me, yet the design is far too complex.

I propose that everything in the file system is an object. Some
objects have names associated with them like conventional file
systems. Some don't because they're not needed.

There shouldn't just one set method for accessing an object (like the
/dir/dir/dir/file of UNIX). In fact going down levels in the file
system might be function calls rather than a simple traversal of
layers.

Let me give an example. The root directory would probably be, by
convention a hash table of named objects. In the root directory we
might have a personnel "directory". (directory isn't really the right
word). The personnel directory consists of a number of person objects.

Now we can go (all-employees (personnel *root-dir*)) to get all the
people, which is a bit like "/personnel/*" in a normal file
system. This is basic stuff and not very interesting. We could also go
(get-name "Smith" (personnel *root-dir*)), which is a bit like
"/personnel/Smith". This is also basic.

But we could just as well go 
(filter (lambda (person) (> age 50)) (get-managers (personnel *root-dir*)))

In order to get all the managers older than 50.

or

(map (lambda (person) 
       (cons 
        person 
        (get-dept (departments *root-dir*) (person-dept person)))) 
     (get-managers (personnel *root-dir*))))

Which would yield a map between people and their departments. Like

(#s("Fred Smith" 52 "Sales") . #s("Sales Dept")
#s("Bill Jones" 28 "Marketing") . #s("Marketing Dept"))

Actually, this is example is made harder than it would be in real
life. In real life the person would probably have a direct pointer to
their department in object database style so you wouldn't have to look
up the department from a separate "directory".

Only with a file system using this general philosophy can "awk" and
"sed" and "perl" style programs be banished from the face of the
earth!

All this talk of syntax in the same general philiophy of UNIX style
"/foo/bar" is much too primitive. That's the second biggest reason why
UNIX is a pain. (The first being ascii files).

Under this system - YOU NEVER OPEN A FILE!!!! Files are not opened
explicitely. Actually you can't really call them files. Objects are
read from disk implicitely.

If you want security, then you inherit your top level object from some
security object. There doesn't have to be just one style of security
object. People will choose different ones according to their
needs. Some might force always asking a real user for a password, some
mught use kerberos. I don't know I'll leave that to someone else.

The point is, we don't need to be locked into a single file system
model, or security model, or property list model. Probably there will
be a few fairly standard and useful objects to implement common
functionality.

This whole philosophy can make LispOS the most powerful OS ever, yet
the most simple at its core.

Any comments anyone?

>Second, there is a distributed, object-oriented database called the Namespace.
>This is mostly an used for managing system and program configuration parameters.
>It's not really very flexible, it's not fast, it's hairy to use, and had bugs.

I think everything should be an object in LispOS nirvana. Not to do
this is to lose about 50% of the advantage of having a LispOS.