On Friday, February 8, 2002, at 09:12 AM, Alan Kay wrote:

> I was just talking about a default convention, since essentially all 
> OS's have files, but only some of them (like Unix) have simple process 
> to process communication. For example, the Mac used to have a similar 
> convention at the user level. The default notion of printing was just 
> represented by a polymorphic command in the File pulldown. This would 
> always work for any document. If you wanted to specify something 
> special about printing you could go to the Chooser and customize your 
> printer. Now it's a little more complicated (and less useful) in the 
> default case on the Mac (I haven't tried OSX).
>
> BTW, why would it be awkward to specify options for a pseudofile kind 
> of entity (even in Unix)? In the old days (even before Unix) one would 
> also use files for this. One file would hold the default options (as 
> text), and another (if not empty) would hold any special options for 
> the printer for special cases, etc.

I'll go one further -- perhaps we should be thinking about remodelling 
the FileStream and FileDirectory objects so that they can directly 
support these kind of abstractions, whether or not the operating system 
does?  Perhaps something along the lines of, but more tractable than, 
Styx in the Lucifer system?  If we imposed our own file-system model on 
the corpus of system resources, might we be able to provide, with proper 
refactoring, for a more robust --and more readily extensible-- system?

If we did that, we could begin with trivial "drivers" as pluggable 
primitives, and build thereupon in Smalltalk code -- the very model that 
worked so well for the rest of Squeak.