[FIX] primRename:toBe: on MacFileDirectory
Richard A. O'Keefe
ok at atlas.otago.ac.nz
Tue Apr 10 23:54:53 UTC 2001
Karl Ramberg <karl.ramberg at chello.se> wrote:
Mac was designed to be a single user system
and I don't think they thought about networks,
several hard drives etc either in the design process.
False. Even the oldest Macs could keep track of the directory structure
on more than one disc (even when they had only one disc drive, like the
Mac Plus I occasionally still use). AppleTalk has been around for quite
a while too. [Quick check: "The AppleTalk Manager" is chapter 10 of
Inside Macintosh volume II. That's pre-Mac II; it was available on
128k Macs. This is the May 1984 edition of Inside Mac.] So Macs have
been networked for at least 17 years now. The Xerox Star that Apple
were inspired by was *definitely* networked; I've seen one in action.
It seems likely that Apple thought about networking very early on.
What's particularly interesting here is Aliases. A MacOS alias (available
since MacOS 6) may not only refer to a file with a different name, or in
a different folder, or on a different device (all of which UNIX symbolic
links handle) but even on a different machine whose file system is _not_
Unix on the other hand is a multi user,
networked system so the design is there after.
Networking came comparatively late to UNIX, other than the uucp stuff which
doesn't have (or need) any particular kernel support. Sockets in 4BSD were
widely criticised. System V had a completely different "transport layer"
library, and I've heard that the current Single UNIX Specification has yet
a third "transport layer" interface. Then we have NFS, RFS, and AFS.
There is an assortment of authentication protocols (check the RPC and NFS
specifications some time). So when you say "UNIX" and "networking" in
the same sentence, you really have to say which version. "the design is
there"? But which one?
I think we have to think of which of these
designs best suit Squeak and do the design there after. Karl
Of course. However, there is always an argument for having a high level
portable interface with OS-specific classes to implement it, which may
additionally support OS-specific quirks.
More information about the Squeak-dev