Re: Mac OS X 10.1 File Name Extension Guidelines [Long]
Re: Mac OS X 10.1 File Name Extension Guidelines [Long]
- Subject: Re: Mac OS X 10.1 File Name Extension Guidelines [Long]
- From: Brendan Younger <email@hidden>
- Date: Sat, 8 Sep 2001 17:25:37 -0400
I must say that I am rather surprised at the lack of interest (or should
I say justifiable rage) on a rather important feature of user-interface
design. It is this lack of interest that is allowing Apple to do *very*
foolish things in the name of compatibility. (No pun intended.) To
begin with, I strongly suggest that all who haven't (including any Apple
Higher-ups) read:
http://arstechnica.com/reviews/01q3/metadata/metadata-1.html. Pay
particular attention to pages 8 onward. This is quite possibly the
best, most coherent and logical request for the elimination of
extensions I have ever read.
Now, eliminating file extensions would probably not be a wise thing to
do right now, especially if Apple wants to keep itself positioned to
have an OS which is the kind of go anywhere, do anything miracle
God-send that IT folks dream about. However, that does *not* mean that
they should adopt the lowest-common denominator for all their features
in order to retain compatibility with every possible system out there.
The goal (a lofty one which I think they had in mind when they embarked
upon OS X but which was gradually lost in the details) is to provide the
richest possible experience for the OS X user while allowing him/her to
interface, use or run, any program, any package, or any interface they
wish. Taken to it's logical conclusion, each Mac is indeed an island in
a sea of other platforms and ways of doing things. This does not mean
that the Mac should be in any way hostile to the other computing
platforms, but rather it should always retain its Macintosh qualities
and when faced with outsider's ways of doing things, the appropriate
translations should be in place. Think about it, presidents and leaders
of countries do not learn the language of every foreign diplomat or
leader which they encounter. They have someone translate. Apple needs
to bear this in mind. They have a rather unprecedented chance to
correct things and do things on the Mac OS that would reflect the
competence and class that they possess. Microsoft does not generally
*fix* things which are wrong with Windows. The underpinnings are a
hobbled mess and rather than make the break, they simply allow things to
be easily broken. How long did it take them to get plug and play even
sort of working? Apple did the correct thing to completely abandon the
OS 9 code base and move ahead to only later give a (very well-written)
method of backwards compatibility. The same should be true of metadata
on the Macintosh. Backwards compatibility can almost always be built in
to the new foundation. The chance to create a new foundation and have
it stick does not come along very often.
Given this, I would like to state that I *fully* support *all* of John
Siracusa's recommendations for metadata. (No, I am not blindly
following the man, it's simply that what he's saying is 90% common sense
and 10% personal preference with which I happen to agree.) I would,
however, like to add my own suggestions and gripes in light of that
horrible document mailed to us entitled: Mac OS X 10.1 File Name
Extension Guidelines.
First, as noted by Siracusa, extensions are *not* necessary on an HFS+
volume. Therefore, ALL NEWLY CREATED FILES SHOULD NOT HAVE AN
EXTENSION! Incoming files, though, should keep the names the same to
ensure that UNIX scripts, etc. are not broken (just like in Mac OS 9).
Now, that means that the Type/Creator codes *must* be set on all new
files. As it stands, the guidelines state that a developer may or may
not set them according to preference. This is ridiculously stupid.
Keep them. It takes about one or two lines of code and it provides a
*much* richer experience. Those who have not had extensive experience
with OS 9 should try the simple joy creating two HTML files. One from
your web browser of the source from the page www.apple.com and the other
from within BBEdit from your own HTML code. Now, when you go to double
click on one of them, each one opens in the CORRECT F#%KING
APPLICATION! Create two HTML files in Mac OS X with two programs that
"didn't feel like setting the type/creator codes" and you get a very
annoying and completely avoidable situation.
Well, now you have all your own files which are devoid of extensions,
can be renamed at will and are bound to the correct application as well
as the files you've downloaded which do have extensions but which *also*
have type/creator codes. Now, you want to send a file to a friend.
This is no problem at all since Apple could easily provide an API to add
an extension to a name just as they have given you a completely
unnecessary one for sanitizing the name to pull the wool over the user's
eyes. Now, there's still a small caveat. When you give those files to
another platform, the names are changed. What if you depend on those
files having the same name on the other platform? Well, you could
prevent them from being changed by asking the user before changing the
names of files about to be sent over a network or you could do something
a bit more tricky. If you know you'll need to access those same files
on the other platform (maybe you're writing a UNIX shell script), you
could quite easily give those files an extension which would then stay
with them, or, if you just plain need a cross-platform solution and have
no idea the history of certain files, simply always specify them with
their path names. That's right, if you created an HTML file on a Mac in
some cross-platform Java application, the application could name it
foo.html. (See Note) The ".html" would be (on the Mac OS) stripped off
so it would become an HTML file called "foo" and when you needed it
again, you would ask for a file named "foo.html". That is, when file
type is specified in the name and no file exactly matches that name, the
filesystem will look for a file of the type specified by the extension
that has the same name sans the extension.
Ok. So, we have are bases covered for when a Macintosh decides to send
or receive files from outside sources. Now, what if outside sources are
requesting files on your machine or you've loaned your hard drive to a
friend and he's reading it with a PC. Let's say your friend needs to
read those cool HTML files you created earlier. He starts looking for
them and finds them but his brain-dead PC program doesn't see that
magical .html on the end of the file and thus won't open them. What to
do? Well, let's see, it's still on an HFS+ volume which means that the
metadata is still there . . . what if the driver was written so as to
provide the .html extension *in the name it returns*? This would solve
everything. Since drivers are absolutely machine/platform dependent, it
shouldn't be too hard to simply append the necessary type data when on a
platform that expects it in the name!
There. Now we have a filesystem which is forward-looking enough to
provide users with the concept of "A file whose name is: and whose type
is:" while not necessarily tying one to the other but still providing
full compatibility with other systems *and* which meets Apple's idiotic
guidelines for specifying an extension. (The extension would be
implicit in some method like: -[NSFileManager createFile:filename
inDirectory:dirID ofType:sometype].) Older programs, especially command
line ones, wouldn't find anything changed. They could still create
files named foo.jpg and foo.html and these extensions would show up.
However, all the more modern applications would use the above
NSFileManager method to create a file which accurately reflects its
contents without mucking up the name and thus returning control to the
user as it should always be.
Please, please, please, someone at Apple take these suggestions
seriously and don't be afraid of doing a little more to keep the
competitive edge.
Brendan Younger
Note: This is not to imply that a user would be unable to specify an
extension if they wanted to. The user should certainly be able to
rename an image file to foo.txt and have the extension stick as well as
the image type. When I said that the application would create a file
foo.html I meant something along the lines of a Save As... dialog in
which the user typed "foo" and the application added the .html. The
system (even though it would be a bit of a hack) could divine that the
user wanted a file named foo. This also covers the application from the
chance that someone renamed the file to simply foo. Even though this
happened, the application could still find the file since the system
would have seen the .html when it was created and put the appropriate
type code in.
P.S. I have referred only to type/creator codes as means of specifying
file type in this letter. I would much rather have a MIME-like encoding
scheme such as the one Mr. Siracusa recommends, so if you feel the same,
feel free to replace every instance of type/creator code with "MIME-like
encoding scheme." It doesn't change anything.