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: Bill Chin <email@hidden>
- Date: Sun, 9 Sep 2001 12:17:44 -0400
On Sunday, September 9, 2001, at 10:13 AM, Mark Munz 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.
In such cases, the files are on your computer in RAM only. There's
no way of knowing what OS the fileserver is running. It could be
a Mac running OS X with HFS+ disks. It could be a Linux box running
NFS. It could be a big high-performance Auspex server. As such,
there is no 'airlock' process where the OS can know that it's
transferring a file to another OS and needs to do the conversion.
Actually, this is untrue. The OS knows what volumes are connected and
their
format. The OS is the one reading and writing from the network drive. It
knows what format it is writing to, even if is based on the protocol
used.
But where do you put this translation layer in so that it doesn't cause
confusion? That perl script is looking for MyGraphic.jpg, but your
Carbon app thinks it's looking for MyGraphic. What if a Carbon app calls
a POSIX routine and passes it a file name? What about users that use
both the GUI and the CLI?
Truthfully, unless someone stands up and fights against it - we'll have
computers 30 years from now that are 100,000 times faster but still
require
us to use .txt to indicate the file is a text document.
True. But the fight has to first be about the way we store data in
filesystems, then about type/creator. Without a major change in the way
use use filesystems, there's no point in debating type/creator.
Type/creator right now is just a hack that limits Mac OS (while
providing some nice features to a small number of people). Right now, we
have a 4 character limit file extension hidden away from the user called
a type. Then we have this creator code that just wreaks havoc on those
of us connected to shared file systems... like most of the computers on
corporate networks and comprise most of the computer market.
Just try sharing the same files on Mac OS X Server between MS-Windows,
Mac OS X, and UNIX clients. Of course, keep in mind that the Mac
currently has roughly 5% marketshare.
If we continue going with the lowest common denominator for all
decisions in
the name of compatibility, what is there that distinguishes Mac OS X?
Ah, but it's a matter of choosing which battles to fight. Which battles
for which Apple has the resources and the technology to implement
without sacrificing too much of the potential market. Certainly Quartz
isn't lowest common denominator. Types/creator as implemented in the
current system isn't worth it. It's not that much better than file
extensions that we should sacrifice Mac OS X's place in the corporate
computing landscape.
Now, an object soup database instead of a filesystem might be worth it
to sacrifice interoperability. Of course, we're not going there anytime
soon.
Why doesn't NFS support more metadata? If we want to advance the
computing
world, let's bring people up to a more advanced system rather than dumb
down
an OS in the name of compatibility. Let's stop looking to the past and
look
to the future to make things better.
You look at this as dumbing down Mac OS X. I see it as fixing Mac OS X.
I think type/creator as currently implemented is broken - it's fine if
you don't want to interact with anyone else, but it sucks otherwise. But
we're not building an platform for 1985. It's not dumbing down Mac OS
X, but rather liberating it. We can then seriously consider integrating
newer filesystem technologies, like xfs, jfs, ext3, afs, coda, etc.
..Bill Chin
M Dimension Technology