Re: Netscape 4.0 press release at their server

 From: "David Perrell" <davidp@earthlink.net>
| 
| > Actually, I would expect the database would be maintained
| automatically
| > - when you install an aplication it would install the types it knows
| in
| > the database.
| 
| The "types it knows" based on a registry maintained by Apple?
---

No, the registered types of the file types it knows how to handle.  For
instance, when you installed FrameMaker, it would add to the local
registry database an entry for MIF and an entry for its binary files; it
would also try to add to the registry entries for file types it can
handle by conversion (such as Word binaries); if no other entries
existed for those types, the registry would add them, otherwise it would
ask the user which application should be the default for those types and
make the others secondary alternatives (which might become primary if
another application is subsequently de-installed).

--- 
| > I don't know what that sentence is trying to say.
| 
| When a file type is enhanced in some way, does it require a new
| registration? If you must your system's file type registry from Apple's
| database, doesn't it get larger each time?
---

Basically, yes.  MIF 3.0 is different from MIF 4.0 and I would like to
be able to have both Frame 3 and Frame 4 installed and have the right
application started for either.  Yes, the registry keeps growing as the
collection of local tools continues to know about more types, but that's
just a reflection of reality - the number of file types keeps growing.
If you did this by extensions, you would need to include versions in the
extensions, 'cause they really are different types.

---
| 
| > What application?  How do you know what application to feed it to?  
| 
| If I send you a pagemaker file from an NT system and there's no
| extension, how do you know what application to feed it to? I have a Mac
| Syquest cartridge sent by a printer who has the most obscure file
| naming convention I have ever seen. If my system doesn't understand Mac
| file numbers, how do I know what applications to feed these files to?
---

That was exactly why I said you needed to have a reliable typeing
mechanism and a local registry of types.  The registry would say exactly
what types the applications on your system understands; by reference to
the master registry you could determine what application is needed for
a number you don't understand yet.

---
| > With registered types you could at least find out what format it is,
| so
| > you could look for a converter or get the needed application.
| 
| Where do I find this info when the sender or poster is not polite
| enough to tell me? Apple Computer? What if I also don't know that the
| file came from a Mac?
---

Well, today, if it's a Mac file type you go to Apple; if it's a UNIX
magic number, you go to whoever now owns that registry (probably either
SCO or X/Open).  I imagine Microsoft also has a registry like that.
My wish is that all those things would coalesce into one (like the
namespace ISO maintains).

---
| > Actually, I've had much better luck with Macs than with UNIX, where I
| > periodically download a file and have no way to guess what kind of a
| > file it is.
| 
| One of my points. Better to standardize extensions for intersystem
| transfers, just as with HTML, GIF, JPG, TXT, etc.
| 
| I don't think embedded file type codes registered with a central
| database are a good idea and you do. It doesn't seem likely this dialog
| will change any opinions.
---

Given the growth of cross-platform file servers, it's an issue that
ought to percolating up the standards interest food chain.  We already
have better mechanisms than extensions (e.g., MIME types, Apple Single,
and other typed archive formats).  But it's the standardization and
registry that's the main point, rather than whether it's an extension or
an internally stored indication.

scott

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
phone:	217-384-8589			  fax:	217-384-8550
internet mail:	preece@urbana.mcd.mot.com

Received on Tuesday, 22 October 1996 18:20:07 UTC