Re: Netscape 4.0 press release at their server

Stuart Young wrote:
> Unfortunately, the problem is choosing a decent seperator. Dos uses a
., 
> and many programs on the mac either use a ., _, or a -.

It's difficult not being slightly centric to a system you've used for
12 years, however bad you may realize it is.

I wanted to pull out of this discussion because (1) I don't feel
sufficiently educated about the MacOS and don't have time to get so and
(2) I kept edging it toward a stupid Mac/PC debate. And I really don't
hate the Mac, even though it never quite suited me. The Mac may be the
most elegant desktop system pre-NeXT, but there's something to be said
for chaos, too. IMO, the Mac wouldn't be as good as it is today without
the explosive hardware evolution on the relatively open Intel/MS side,
and NT wouldn't finally be getting a good interface without the Mac.
Both platforms have benefited from advantages in the other.

But back to file registries. The sensible part of the discussion was
simply whether file type should be in machine- or human-readable form. 

Part of my argument against machine-readable was emotional. Surely the
system database does _not_ need to be upgraded in toto from a central
database as I suggested -- the applications themselves update the
database, just as the file type association database is updated in Win.

BUT, aren't there alternatives to a central database? File types have
become much less proprietary since the days of .PCX (the worst
compression scheme ever invented a 'standard'?! -- damn good thing the
PC side stayed chaotic!) and some (Tag Image File Format being
especially notable) are structured such that applications can recognize
and deal with even enhanced versions of the format, no matter what
system the file was created on. Can't universal file types evolve such
that a central database is simply not necessary? Why should
standardization revolve around a numerical code with no inherent
meaning?

Version numbers of such file types do _not_ need to be part of a
filename extension. As an 'open' file type evolves, programming-related
information would be readily accessible.

> There is another way. Using such a central registry on the
programmers 
> end, and sticking slightly on some conventions. This means that you
have 
> to binary search the start or end of the file for a particular tag,
but 
> it can work, and isn't that hard to implement.
> 
> The central registry is only useful to programmers to get a list of
file 
> tags so they can embed them in their programs (and since a new file
type 
> would change the tag, you can't use new file types, not that the
program 
> would understand the new file type anyway, because it can't decode
the file!)

You are vaguely describing TIFF, and a later version of TIFF includes
features of the previous. A later TIFF version need not break an
application's ability to read the file unless it utilizes tags the
application can't understand. Even then some of the information may be
usable.

It still seems to me that the only need for a central registry of file
type codes that are distinct for every version is in deference to the
MacOS. And not a good idea.

David Perrell

Received on Thursday, 24 October 1996 16:35:37 UTC