app filetype-registration, how?

[David Jeske <jeske home chat net>]

On Mon, Aug 17, 1998 at 02:59:27PM -0400, Stuart Parmenter wrote:
> Is there really a point to this conversation? 

Agreed that everyone in this conversation (including myself) went
quite a bit off topic.

> What it sounds like to me, is that someone needs to create an ORB
> server that has a mailcap-like database, which is asked what
> application needs to be used to handle certain files.  If there is a
> GNOME application that handles the file, then it can be asked if it
> can open the file, and if so, then it does, otherwise the server
> looks for other applications until it finds something.  If it fails,
> it could pop up a message to the user saying it doesn't know what to
> handle it with, or it could open it in vi or emacs or something.

Exactly. However, it's not as trivial as that. 

** How are applications going to publish to this ORB server that they
** can handle a given filetype.

The idea I was trying to get across is that the UNIX solution "edit
/usr/local/etc/Gnome/app-orb/applist" is not a good answer. Nor is
just hacking RPM to edit it for you.

We want a robust solution. Systems out there (like the UNIX text file,
or the Windows registry, or the BeOS 'register type' API) have trouble
because the registration of types gets out of sync with the
applications. MacOS/NeXT do a better job because the application
'wrapper' itself passively exports the types it opens to the
system. Any database of type->app information is just a cache of data
which has been pulled from the apps themselves. In both of those
systems, the icons are also stuck into the apps. 

For example, in NeXT, OmniWeb is the web browser. OmniWeb.app is
actually an opaque directory which contains many files, just like all
NeXT apps. Inside that app-wrapper, there is information about (a)
what filetypes OmniWeb opens, (b) what icons those filetypes should
have if they are going to be opened in OmniWeb, (c) what 'Services'
OmniWeb exports to the system (services are an interapplication
communication thing, like a really loose CORBA). This allows the 'type
registry' to go scan all the apps and find out what filetypes everyone
can open. If you delete an app, the filetype registration can go
away. If you copy an app off an FTP server, the filetype registration
works. It's a robust binding. 

I think this kind of robust binding is what we should be doing.

Of course, there is also a second component to that, where the user
will want to setup prefernces for 'which web browser' will open his
HTML files. However, you don't get that far until you have the list of
programs which can open HTML files.

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