Re: Mac OS X 10.1 File Name Extension Guidelines
Re: Mac OS X 10.1 File Name Extension Guidelines
- Subject: Re: Mac OS X 10.1 File Name Extension Guidelines
- From: "Kenneth C. Dyke" <email@hidden>
- Date: Mon, 10 Sep 2001 22:07:42 -0700
First, the following is purely my opinion. I don't speak for Apple, or
anyone else for that matter. I'll try to avoid sticking IMHO's
everywhere to avoid clutter, but insert them freely as you wish.
This will ramble a bit, but what the Hell...
Every time this discussion of filename extensions versus
type/creator/etc. comes up, I feel like I'm watching people flame each
other over who's 15-20 year old solution sucks less, and no one tries to
actually propose anything better, which is probably why the discussion
never moves forward.
Honestly, I do think both "solutions" suck, and for different reasons.
Filename extensions suck because they shouldn't be necessary at all, and
type/creator suck for similar reasons, but additionally because of
multi-user issues. I go into more specifics in a bit.
First let's talk about file types only. The fundamental flaw with both
of the current schemes is that they are just plain wrong. A file's
type is ultimately determined by it's contents. A JPEG file is a JPEG
file regardless of what extension you put on it, or what kind of
meta-data you try to attach to it. Any system in which an application
is present that can load JPEG files can't do it (or refuses to do it)
just because it's named incorrectly or has the wrong meta-data attached
is flawed.
For probably the vast majority of file formats out there, you could
probably write some code to determine what kind of file it was with a
lot of accuracy, and you could certainly do it 100% for any new kinds of
file formats. Things like Targa files, which don't have any useful
identifiers in them, are problematic but oh well.
Given this fact, why not propose a system whereby the OS is actually
able to interrogate files as to what they are in order to assist with
decisions about what applications can actually handle the file?
What I'm thinking of is that application bundles could have an
additional CFPlugIn included that could be loaded by the Finder (or
whatever). These plugins would communicate with their loader via a
filesystem-like interface that would let them sniff at the bits of the
file, and would also be able to provide information back to the Finder
about what they think the file is (perhaps via MIME types), as well as
whether or not their parent application can load them or not, and what
kind of confidence level they have in their identification.
Now, someone is going to immediately pipe up and say "but that would be
too slow!". Maybe, maybe not. The main case where performance would
probably be the most critical is when figuring out what icon to use for
a file or in a file dialog that's trying to filter out files, but
perhaps something creative could be done here (suggestions are welcome).
I'm double-clicking the file anyway, it's not going to matter if the OS
did some extra pre-reads on the file since the opening app will probably
read the same data anyway, and then the data would already be in the
filesystem cache.
My take an this is that I have a machine would orders of magnitude
better performance than anything from the 1980-1985 timeframe that I'm
willing to spend some of that performance for a better user experience.
A modern Mac can probably read a significant portion of a file in less
time than it takes a circa-1980's PC to spin up a floppy drive.
The other issue at hand is answering the question of "which application
should a file be opened with, all other things being equal?". This is a
tough one, but whatever the solution is, it really needs to be
multi-user. My choice would be to simply have a few layers of choice
here. The first level would be a global setting that says all JPEG
files should be open in one particular app unless I override it. It
might even be nice to be able to change this behaviour for different
locations in a filesystem. The Finder-like entity could also track on
a per-file basis what the user's preferred application is, but it
doesn't need to do this along with the file itself if there is some way
to uniquely identify the file even if it moves. The reason for not
keeping it with the file is that the information may get lost in the
transfer anyway, and it's not always going to be useful if transferred
to a different machine, anyway. The other reason is that you may not
have write-access to the file or even the filesystem the file is stored
on.
Anyway, that's my $0.02 on the matter. I just want a system that
doesn't get as easily confused as the current schemes do. I don't want
to need some stupid third party app to fix type/creator codes when they
go wrong, and I don't want to have to rename files to make things work
right, either. This kind of stuff should Just Work(TM), and there's no
excuse IMHO for it not to.
P.S... One additional data point: My home directory here at home is
mounted via NFS to a NetBSD machine over 100mbit ethernet, and has 419
files in it. After a clean reboot and log in, doing "time file *
>/dev/null" took 0.190 seconds of user time, 0.100s of system time and
3.88 seconds total. Presumably that was doing a lot more work than
you'd normally need for a directory scan, which in the case of Finder
could be a lot lazier.
-Ken
Kenneth Dyke, email@hidden (personal), email@hidden (work)
Sr. Mad Scientist, MacOS X OpenGL Group, Apple Computer, Inc.
C++ is to C as Lung Cancer is to Lung