Thanks Lex I will investigate those packages, my comments were very off the
top of my head.

The thing that happen that fired the thought was I was looking at all
sub-instances of ...um... FileStream I think. Anyway I found in the base
image for 3.7a there was a FileStream with a Mac file name. Seemed a bit
silly to me.

Translation issues would be the biggie I agree. Does anyone know what would
happen on a machine running a web server if the file names could have
Unicode or other characters, etc? How does the web server translate URIs to
those formats?

Russell

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Lex
Spoon
Sent: Wednesday, 21 April 2004 1:28 AM
To: The general-purpose Squeak developers list
Cc: 'The general-purpose Squeak developers list'
Subject: RE: FileDirectory>>fileExists: (was: Re: [BUG]Unable to load
BFAV,various problems )

"Russell Penney" <russell.penney at tincanct.com> wrote:
>    Could one approach to this be to use URI's as Squeak's native file and
> directory naming? These could be translated by a primitive to a os native
> representation but Squeak users would never see that.

I think this is what Andreas is getting at.

Does anyone know of systems that have gone this route?  How well did it
work?  Surely some language has tried it at this point.

There are some issues.

First, it means that users cannot enter filenames in the native format
they are used to.  This can easily be confusing!

Second, not all URL's will work on all platforms.  Some platforms use
7-bit filenames, others use Unicode.  Some platforms allow $/ and $: in
filenames, and others do not.  Some platforms have a 14 character limit
on filenames; others, have 8+3 as the limit; others have 255.  Probably
all have *some* limit, though URL's do not!

This last issue is particularly tricky because there are problems
whether you use a least common denominator or not.  If you restrict the
URL's to things that work everywhere, then you get into problems when
someone lists a directory and that particular directory contains files
that are already illegal.  And of course if you allow any URL that will
work on at least one platform, then users can enter stuff that won't
work on the current platform.

Overall, it sounds like a reasonable idea, but it is not trivial.  We
will still need to deal with naming issues, and we should still, I
think, have a way to access filenames in the native format.  This latter
could be as simple as having a primitive to convert from native format
to the generic format.



> I would say it's a lot of work but the benefits would be huge. For example
> Monticello respositories would be entered as a URI and one class handles
the
> distinction between file, http and ftp.

We already have that.  In fact, we have it twice.  There is the URL
package and the URI package, and they both have file URL's in them.


-Lex