• 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: j o a r <email@hidden>
  • Date: Mon, 10 Sep 2001 15:13:12 -0700

On Sunday, September 9, 2001, at 12:29 , Jonathan Hendry wrote:

Ah, but now we can use extensions like .MDDesktopConfig, or .ooutline,
which beat the heck out of .txt or 4-byte codes.
Besides, the type is, undeniably, useful information. I find it reasonable
to put it where it's readily available.

But the type is readily available already. In list view of the Finder you have the type column - ie. "Adobe Photoshop 6.0 document", and in icon view you have the icon...
The difference is that in a system based on rich meta data instead of file name extensions, the system can display so much more, and more correct, information in the type column then would be practically possible in an extensions based system.

On Sunday, September 9, 2001, at 09:17 , Bill Chin wrote:

Wait, isn't putting the definition of what type of document I'm dealing with
a throwback to the early years when disk space was expensive and in short
supply, when saving 4 bytes was crucial, when we used .txt to define a text
file and such. Apparently we haven't come very far.
Actually, with file name extensions, I can create an application that uses .hypertext as an extension under Mac OS X today. With current HFS+ implementation, we're limited to 4 character type codes (HTXT). Which one is more limiting?
And you're right. We haven't come very far.

But you are completely missing the point here. The four character type/creator (T/C) code is - as the people on this list who likes math have already proven - plenty enough to encode all our document types for ages and ages to come. The point is that this code isn't intended for human consumption, mnemonics aside. What makes T/C so much superior is the power of _abstraction_!
If you were creating a table of users in a database, would you use peoples names as the key to the table? No, you would use a separate ID because it gives you so much more freedom and power later on.
Because of the abstraction available in the T/C system we can display the type of documents like "Microsoft Word 2001 document". If we were using file name extensions alone, we would only know that it was a "Microsoft Word document" - see the difference? How many versions of the ".doc", ".psd", ".gif", et.c. formats are in reality out there? Since they are all typed using the same extension, the extension gets next to useless - not for Microsoft of course since this ensures that the only foolproof way to know that you can open a ".doc" document is to own the very latest version of Word...
A system with no abstraction between the data that developers use and end users see is stupid beyond comprehension.

We have to live with it, since we're a minority, but we don't have to be contend with it - and should strive to find something better, not only for the Macintosh community, but for every computer user. Reading this thread makes me wonder if you belive that communication between camps are impossible? There is a difference between business and war after all...

j o a r


  • Follow-Ups:
    • Re: Mac OS X 10.1 File Name Extension Guidelines
      • From: Lloyd Sargent <email@hidden>
References: 
 >Re: Mac OS X 10.1 File Name Extension Guidelines (From: Jonathan Hendry <email@hidden>)

  • Prev by Date: Re: Mac OS X 10.1 File Name Extension Guidelines
  • Next by Date: Re: Would Any Developers Use This?
  • 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