Re: app filetype-registration, how?

[David Jeske <jeske home chat net>]

On Mon, Aug 17, 1998 at 10:38:45PM -0600, Tom Tromey wrote:
> >>>>> "David" == David Jeske <jeske@home.chat.net> writes:
> 
> David> ** How are applications going to publish to this ORB server that they
> David> ** can handle a given filetype.
> 
> When application A wants to edit file F, it talks to some kind of name
> service to find the object that can service its request ("edit F").
> 
> I don't know the precise form of this negotiation.  One idea is to use
> something like the CORBA Naming Service, though perhaps this is too
> simplistic.  Another is to use something like the CORBA Trader
> Service, though perhaps this is too big.
> 
> Anyway, whatever service it is will have an API for asking questions
> of a certain form.
> 
> Ok.
> 
> So the answer it will also have an API for registering a file type to
> application mapping.  Then applications can just run a special program
> at install time which will set up this mapping in a global way.

This is IMO a _very_ bad idea. This is how Windows is. You just
described InstallShield. What happens when someone deletes the app?
What happens when someone moves the app? These relationships would
have to be tracked. As an informed opinion, from someone who has used
Windows, Linux, Mac, OS/2, NeXT, Pilot, and many others, all quite
extensively, this is the wrong road to go down. It's much nicer to
have things robust, where installing an app dosn't touch any files
outside of the encapsulated app package.

There are many ways to do this. I like the PalmOS's (on the Pilot)
idea that users shouldn't touch app files. You just "install" the
app. If you want to delete it you go to the app manager and delete
it. You don't even know where the files are stored.

However, we've got some serious UNIX backward compatibility to deal
with. UNIX has complex things like: multiple versions of the same
program, partial installation, permissions for different parts of the
filename space.

NeXT came up with what in my opinion is a very nice compromise. They
used the standard unix filesystem, but made it so that anything that
is involved with the 'install' of an app is contained within the app
wrapper. For almost all apps, installing is nothing more than
'untarring' the app onto the drive. This provides a robustness, in
that you can move, delete, or copy in apps without having around the
silly little install programs like InstallShield.

I say almost all, because some apps were designed to interact with
legacy parts of the system, and thus needed to resort to legacy
install methods.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net