Re: Mac OS X 10.1 File Name Extension Guidelines [Fairly Long]
Re: Mac OS X 10.1 File Name Extension Guidelines [Fairly Long]
- Subject: Re: Mac OS X 10.1 File Name Extension Guidelines [Fairly Long]
- From: Brendan Younger <email@hidden>
- Date: Sun, 9 Sep 2001 13:36:35 -0400
Well, since it was kindly pointed out to me that my previous rant might
have been a bit long, here's the short version.
If Brendan Younger were running Apple's UI design shop:
What Apple needs to do to provide the richest possible experience as far
as file typing is concerned:
1. Either enforce the setting of type/creator codes or come up with a
new, fully modernized way of typing a file. (eg. The MIME-like typing
suggested by Siracusa in
http://arstechnica.com/reviews/01q3/metadata/metadata-1.html.)
2. Create a new API along the lines of: -[NSFileManager
createFile:filename inDirectory:dirID ofType:sometype]. When saving to
a volume which doesn't support the typing metadata, then append the
appropriate extension to the file.
3. Have all applications provide a dictionary of the types they can
read/write and the equivalent extensions. (This is how the system knows
what extension to use for #2.)
4. Allow a file to be specified in two possible ways. Asking for a file
of type "HTML" which is named "Moof" and asking for a file named
"Moof.html" are precisely equivalent. That is, if there exists an html
file named "Moof", both methods return the same file (unless there
exists a file named Moof.html also, in which case the second method has
no problems and the first returns both files).
5. When a foreign system which does not know of HFS+ metadata asks for a
directory listing, the filesystem returns names with the appropriate
extensions added. This is the kicker. This is probably why Apple wants
extensions on all files, so that other systems know what to do with them
even when they reside on HFS+ volumes. However, in the utopian future,
most, if not all, filesystems would be able to at least understand some
of the metadata and hence the display of file extensions would be simply
a weaning process.
It is important to note that the above system performs almost exactly
like the one described and apparently blessed by Apple. What, then are
the advantages of my system? Not only does it provide a clear path to a
future without file extensions, but it helps in the following example:
Let's say I'm writing a shell script for some package that I've made. I
have a text editor and a finder window open. When referring to the
names of the files, I go on what I see in the Finder window. If I have
extensions turned off, I never see the extensions and thus get the names
wrong. If I have extensions turned on, I may still get the names wrong
because some files may have the "Hide Extension" bit set. I should not
have to resort to the Terminal simply to tell what the *real* filenames
for my files are. Now in my system, I can see any and all extension
which I have *explicitly* placed in my file's names. Thus, my shell
script works.
Please Apple, don't do something silly when it could be done better and
in a more elegant fashion. Please.
Brendan Younger