Concerning symbolic links/aliases, I wrote:
	> That's why we have platform-specific implementations of generic features, no?
	
Lex Spoon replied:

	I don't think you are proposing that *all* platform-variant features
	have a generic version?

Of course not.  I was talking about one specific feature which is not
limited to a single platform but is available on UNIX, MacOS (X and pre-X),
and some versions of Windows.  The feature even had an analogue in TOPS-10
and arguably has a close relative in VMS.  In short, I was talking about
something where there *is* a generic concept across many but admittedly
not all platforms.

Let's face it, not all platforms have a notion of 'directory';
was that taken as sufficent reason to exclude generic directory
support from Squeak?

	Assuming you agree, what criteria should be used to decide what is going
	to be available Squeak-wide?

"Available" is a rather fuzzy word here.

There's a spectrum of possibilities:
 (0) No support for a feature at all.
 (1) If you want the feature, roll your own platform-specific FFI
     code or plugin.
 (2) Someone has put up a project with the platform-specific code
     you need.
 (3) Someone has designed a reasonably generic interface that makes
     sense for several platforms, and you can download this and the
     implementation code you need for the platforms you care about.
 (4) Not only has someone done this, but it actually works in the version
     of Squeak you have.
 (5) The feature is maintained as part of a well supported module that is
     part of the "standard Squeak" even if it isn't in the base image.
 (6) It's in the base image.
That's far from all the possibilities, of course.

What criteria?  Cost/benefit, like always.

	I've been arguing based on trying to interpret Squeak's gestalt,
	which has to do with authoring and sharing computer media.

I see link support as part of 'sharing computer media'.

	We should have the minimum necessary to support that gestalt,
	because larger requirements make porting harder.

"The minimum necessary to support that gestalt" is not a very well defined
concept.  I haven't a clue how to use 3D graphics in Squeak, so to me it's
not part of the necessary minimum.  Other people will naturally have other
ideas.  I don't know how to dynamically vary the tuning of music with
Squeak; it can make music sound noticeably better, so I would regard it as
part of the necessary minimum, but other people will reasonably differ.

Remember that there is an important difference between the services
Squeak *requires* simply to exist, and the services Squeak "forwards"
to Squeak programmers.  Services that Squeak requires (like a C compiler)
affect portability more strongly than services that Squeak simply forwards.

	> >From time to time I put together a directory for a class that contains
	> a bunch of (file system) links to other tools, so that they can be run
	> from that directory.  It would be nice to do this in Squeak rather than
	> csh or the MacOS Finder.
	
	Okay, good example.  But I think you'd be even happier with a
	MacFileList, than with a generic FileList that can do just a little of
	the stuff you'd like.  Surely once you start using Squeak in place of
	Finder, you'll want to add other Finder-ish features as well, e.g.
	modifying file properties?
	
Quite the opposite.  I have a UNIX box on my desk and a MacOS box (running
MacOS 8.6) and I want the SAME FileList on both of them.  (I also want fonts
that work well on a 96DPI screen to be used without me having to jump through
hoops, but that's another and sadder story.)

The point I was making was precisely that MacOS aliases and UNIX symbolic
links have enough in common to be used without caring which kind I actually
have.

	I don't know much about Macs, but on Unix, I'd want a useful file
	manager to (off the top of my head):
	
		1. handle hard links, too.
	
		2. handle permissions.
	
		3. handle creation and description of non-files such as device nodes.
	
		4. handle locking.
	
A system-specific file manager could do these things, although I note that
the GUI file manager on my UNIX box _doesn't_ handle 3 or 4.  It _does_
handle starting an application and printing a document, but those are
hardly UNIX-specific, are they?

	On the other hand, when I'm doing Squeaky things like publishing a
	project, none of the above are useful.

What has that got to do with the price of fish?  Is publishing a project
the only thing we do with Squeak?  When I'm crunching XML files in C,
I'm not using floating-point at all, but that doesn't mean C shouldn't
support floating-point.  I don't think there is any "Squeaky thing" other
than "whatever some Squeak programmer/author wants to do in Squeak".

However, I would say that I think better internal documentation is more
important to more Squeakers more of the time than links/aliases are ever
likely to be.