Re: Type/Creator codes
Re: Type/Creator codes
- Subject: Re: Type/Creator codes
- From: Fritz Anderson <email@hidden>
- Date: Sun, 13 May 2001 14:54:36 -0500
At 4:28 PM +0200 5/13/2001, Uli Zappe wrote:
Am Sonntag, 13. Mai 2001 um 15:38 schrieb Dave Horlick:
2. I have no immediate visual feedback on what to expect when I
double-click a file
What about *the icon*?
That doesn't help anything if which app the file will open in
depends on the creator, not the type.
Let's be clear on the alternatives here. You suggest that when you
double-click a file under type-creator, you open an application that
_never_ is the one you want, and you suggest that under extensions,
the application that opens will _always_ be the one you want. I
might be accused of saying exactly the opposite. Neither position
can be correct.
There are separable issues before us.
The first is how the user chooses to identify the file. (WHAT -- is
your name?)
The second how a file should advertise its content -- what clues it
gives to the proper interpretation of the byte stream it represents.
(WHAT -- is your quest?)
The third is how the OS chooses an application to view or edit a
file, when the user does not specify the application. (WHAT -- is
your favorite color?) In Life, as in Art, the third question varies,
and is not perfectly resolvable in all cases.
The classic Mac OS treats these separate issues orthogonally. It
gives separate answers to the three questions. HFS was designed to
support the giving of those separate answers.
A pure-extension rigime gives the same answer ("Arthur, King of the
Britons dot The Holy Grail dot the favorite color of everyone else in
quest of The Holy Grail") to all three. For the first two questions,
the answer is more than necessary. It is like a function
RealPart(imaginaryNum) returning imaginaryNum unchanged, with notes
in the documentation suggesting useful bit manipulations. You would
not accept an API that worked like that, if you hadn't learned it
before you had formed any judgment on the matter.
For the third question, pure-extension is less than sufficient: In
the case of .html files, for instance, the user must either view
every file -- even the ones he is writing -- in a browser; or edit
every file -- even the ones he downloaded for reference -- in a text
editor.
It is my experience that creator codes don't answer the third
question correctly all the time, but they answer it correctly more
often than type-coding alone does.
But! you may argue, you are not advocating a rigid, insufficient
answer to the third question! You want the user, to be able to
specify, for a given document, what application to open when the
document is double-clicked.
Just so. You are agreed, then, that file type (whether encoded in
the name or in metadata) isn't enough. Extensions are not enough.
We need additional information that is not _in_ the name of the file.
A designer who agrees that double-click behavior should be
specifiable for single files, has committed himself to metadata.
Call it an editable creator code or not. Store it in the file system
catalog, or in a Desktop Database or in XML .plists as you like. The
debate over metadata is over; metadata wins.
The only issue that remains is how the metadata for a single file is
to be specified. Mac OS X has only one mechanism to do so -- type
and creator codes. That mechanism is not available for all file
systems, but that does not make the present alternative -- no
solution at all -- better. The unavailability of metadata outside of
HFS owes to Apple's failure to recognize that it is committed to
metadata, not to metadata's being a bad idea.
When Apple produces a file-metadata system that is better than type
and creator codes, I'll adopt it enthusiastically. When HFS dropped
the idea of a "working directory," working directories were gone from
my code -- I don't believe the first solution I've learned is a
shadow of the Platonic Ideal of the only possible solution. I'll
accept a radical alternative, but not an inferior one. (I submit
that such an attitude is Apple's, and NeXT's, _only_ excuse for
existing.)
It distresses me, therefore, to hear engineers who are working on the
metadata problem frame the problem as one of "better extensions." It
is assumed that the perfect solution to the problem _must_ be a
naming convention. The failures of all previous naming conventions
only goad the Cocoa team to fanatic efforts to find PERFECT naming
conventions. Any shortcoming in a solution will be tolerated (user
burden, incorrect answers to the Third Question, fragility,
increasingly arcane attempts to conceal actual file names from
greater or lesser parts of the human interface), so long as the
solution is some kind of naming convention. It is a choice of the
inferior out of fear of the radical. This is the Windows (or
Design-by-Summer-Intern) Disease. Great engineers, mature engineers,
don't get stuck that way.
Guys, give it up: The use of extensions was an attempt to have a
file system that could only store the answer to the First Question,
be able to answer the Second as well. Now we've run into the Third
Question. More Questions may come. Stuffing all the answers into
the name was _not_ done because it was the One True Way; it was done
because it was the Only Available Kluge. With limited exceptions,
the kluge has sprung too many leaks to save.
Besides, as I wrote in another mail, you'd need an icon for each
possible extension (note that Unix programs define extensions, but
not respective icons).
If by "Unix programs," you mean command-line tools, that is correct,
but not helpful to our discussion of a human interface intended to be
exclusively graphical for the vast majority of its users.
If you mean programs written for one or another graphical wrapper on
UNIX, I agree that that is the state of affairs, but I do not think
it should control our discussion. I expect that in a year or two,
there will be ten or a hundred Mac OS X users for every user of any
previous UNIX. NeXT was bound by the legacy file systems Microsoft
and AT&T permitted them, and by what developers for those systems
thought was good enough for their users. Apple isn't. The
limitations of the UNIX legacy, as an historical force, are
insignificant compared to what Apple can -- should -- do with Mac OS
X.
-- F