"Lex Spoon" <lex at cc.gatech.edu> wrote:
	> lineends
	
	Hmm, how about ammending this to "text vs. binary mode"?  The reasoning
	is that line-end convention is only needed for dealing with text files,
	and as discused in a recent Mac thread, there is also the issue of
	character set when manipulating a text file.  If the VM knows whether a
	file is in text or binary mode, it can do all necessary translations to
	Squeak conventions internally.  (Note, this isn't an encumbrance to
	initial porting time (a nice feature of Squaek!): you can leave binary
	and text mode the same, to get started.)
	
	
Note that XML requires XML processors to accept any mix of LF, CR, and CR+LF
line ends in an XML document.  Given that I often need to move files between
UNIX and MacOS, and given that Fetch seems to be very bad about ignoring my
settings of the Text/Binary switch, I've had to write enough C code that
handles multiple line end conventions automatically to know that it is not
particularly hard and not particularly inefficient.

However, line ends matter when you are WRITING a text file.  Squeak could
make a guess about the line end convention you want, based on the operating
system you are using, but it would still remain a guess.  If you were writing
something that was to be sent over the net, you might want CR+LF, even though
the program was running on MacOS or UNIX.  And in these days of file systems
shared between disparate operating systems, the fact that I'm writing a file
on a UNIX box doesn't mean that I don't intend it to be viewed as is by
Windows users.

So we do need a way for character set and line end convention to be guessed
automatically by Squeak *AND* over-ridden by the programmer before it is too
late.

	Now, a related issue is that we need to decide whether, from Squeak's
	perspective, OS text files exist at all!

If you don't care whether Squeak can be used to process files that are also
processed by other kinds of software, clearly OS text files need not exist.
If you _do_ care whether Squeak can save out a Postscript file that Ghostview
can read (for example), then OS text files _do_ exist and had better be dealt
with.  I don't fancy converting 150MB files (and I do have a couple) to and
from some esoteric format every time I want to process them.

	MacOS, MSWindows, and Unix all have links.  Unix has two kinds.  It
	sounds more complicated than what Squeak wants, to me, however.  Do they
	really behave similarly enough to be useful?

I don't know about Windows, but MacOS "aliases" and Unix "symbolic links"
are similar enough for a common interface to them to be useful.

	I know you have a use in
	mind, but copying works okay for it, and even copying isn't clear to be
	necessary in the future.
	
Actually, copying DOESN'T work okay.  If you copy a MacOS application, quite
often the copy doesn't quite work because it is looking for other files in
the directory where the copy is, not the directory where the original and
the related files are.  Making an alias _does_ work.  Making a symbolic link
works in the related case in UNIX for a somewhat different reason, but does
work.

	Simple is very good....  Also, not *every* platform will have links, so
	it would suck if code starts relying on their presence.
	
Since links can be used like other names, there are probably people ALREADY
relying on using links to set up environments that Squeak runs in.  Now that
OSProcess exists, that horse has already bolted.