Re: Type/Creator codes
Re: Type/Creator codes
- Subject: Re: Type/Creator codes
- From: Fritz Anderson <email@hidden>
- Date: Sun, 13 May 2001 06:32:34 -0500
We have heard from the Cocoa team -- repeatedly -- the admission that
file-naming conventions are a bad way to encode file content. We
also hear...
10.0 is not the final
word on how extensions will work on Mac OS X. We are looking at ways to
enhance things such that the user experience of file extensions is at
least as good as the user experience of Mac OS file types on Mac OS 9,
while retaining the advantages of file extensions --- the fact that they
are web-friendly and cross-platform. More on this later. (By that I
don't mean later today!)
I can't make sense of this. We are presented with three ways of
attaching type to a file -- type-and-creator (codes), name extensions
(extensions), and, apparently, an engineer's boast that he can
imagine a future method (Nirvana) that might be better than either.
Everyone admits, then, that the merits of
extensions < codes < Nirvana
And everybody admits that of the three, Nirvana doesn't exist. This
would seem to leave
extensions < codes
... but apparently we are being told that because Nirvana _might_
exist some day, we should prefer the _worse_ of the existing
alternatives. This seems to be the advice of the Cocoa team, but I
can't imagine why.
Until Nirvana arrives, best practice under Mac OS X -- as defined by
a successful human interface supported by thousands of developers and
millions of users -- is to set type and creator codes whenever
possible. If Apple chooses to force encoding type information in the
name, code setting will fail, and you make up for the defect in your
exception handler.
The place for cross-platform considerations is where the data crosses
platforms. Not in the user's work routine; file names, like other
user-editable properties, exist to serve the user, not the other way
around. Under the OS Formerly Invented Here, there are mature ways
of making those transformations at the platform-crossing point. One
can argue that Internet Config and File Exchange are workarounds, and
need user maintenance, but they work almost all the time, with less
error or user burden than the scheme the Cocoa team urges.
I can't be actively hostile to extensions. First, they are
wonderfully useful in choosing a parser for a text file, and for
similar organizational tricks in automated file-handling. (A good OS
should support the needs of _both_ daemons and humans in naming their
own files. I implore you to think it possible those needs might be
different.)
Second, so long as Apple remains agnostic about the merits of file
metadata, Mac OS X will be unable to encode or recover metadata in
non-HFS file systems. (And the anti-metadata party within Apple will
then use its failure to do so as proof that metadata is Too Hard To
Do.) Therefore developers have to provide users with as much
remedial support on extensions as they can.
But on the merits of what works well today, best practice is to
supply type-and-creator if at all possible, extension if absolutely
necessary. While recognizing that _making_ it absolutely necessary
is on the agenda of at least some of Apple's OS designers.
-- F