• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Mac OS X 10.1 File Name Extension Guidelines
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Mac OS X 10.1 File Name Extension Guidelines
      • From: Chris Gehlker <email@hidden>
    • Re: Mac OS X 10.1 File Name Extension Guidelines
      • From: Ondra Cada <email@hidden>
    • Re: Mac OS X 10.1 File Name Extension Guidelines
      • From: "John C. Randolph" <email@hidden>
References: 
 >Re: Mac OS X 10.1 File Name Extension Guidelines (From: Lloyd Sargent <email@hidden>)

  • Prev by Date: Objective-C EOF Applications on MacOS X...
  • Next by Date: TextViews update from NSThread
  • Previous by thread: Re: Mac OS X 10.1 File Name Extension Guidelines
  • Next by thread: Re: Mac OS X 10.1 File Name Extension Guidelines
  • Index(es):
    • Date
    • Thread