mime-type/application mapping spec, take #2

Sat Jun 28 21:34:24 EEST 2003

Hi,

The last thread about having a standard way to find out which apps can
handle a given mime-type ended up more or less unconclusive. After an
enlightening discussion with jrb at guadec, I updated the spec I already
sent to describe more in details how to store the necessary information,
and how to do the look up. The main difference is the added "Getting the
applications associated with a mime type" section.

I'm bugging you with that since I plan to rework the GNOME code which
does that, and I'd really like to implement something which is already
standardized, rather than designing my own system, and then change it
again when there is some agreement on some different spec...

Thus it would be really great if we could come to an agreement on that
;)

Cheers, 

Christophe
-------------- next part --------------
This suggestions relies on two distinct groups of files. 

The first is the "application registry" which is created from .desktop
files and contains detailed information about an app which can be
associated to a mime-type. These .desktop files are extended so that
they can be used to specify the mime-types they should be associated 
with.

The second group is a mime hierarchy which contains the list of all 
known mime-type as well as some information about them, including 
links to .desktop files they should be associated with.

The ?? Getting the applications associated with a mime type ?? will explain
why there are those two distinct groups of files, and how to look up the 
applications associated with a mime-type.

It's not possible to associate a mime-type with an app which don't
have an associated .desktop file. When an app which does not have a 
desktop file is associated with a mime type by the user, we create
a dummy desktop file.

Extensions to the .desktop file format:
======================================

Extension to .desktop files describing an application:
They can contain a field MimeType which is a list of
supported mime types along with their priority. The lowest this number
is, the more appropriate this app is to open files having this mime
type (FIXME: this doesn't fit well with the multiple-actions-per-desktop-file scheme
(ie a .desktop file doesn't describe one way to launch an app, but several: 
view, edit, ...)). 

Other fields necessary (to provide equivalent functionality with what
is currently in GNOME):

can_open_multiple_files (same for expect_uris) can be replaced by the 
parameters to the Exec field. Seems a bit hackish and error prone though

uses_gnome_vfs will be a gnome extension

supported_uris: gnome or not gnome ? (this currently lists the various
url schemes an app can open: http, ftp, ...)

=> this allows app writer to easily associate their app with specific mime 
types without having to create tons of files

Mime-type storage
=================

=> Use the xml mime type format described in the current shared mime spec, 
with some customizations.

Additional tags:
an application will be associated with a mime type by adding a  .desktop file 
name and a priority
<mime-handler>
	<desktop-file>some-desktop-file.desktop</desktop-file>
	<priority>65</priority>
</mime-handler>

Extensions which will be gnome specific:
default action type (component/application)
component association

each application which is associated with a mime type must have an associated 
desktop-like file (this makes things easier if eg the user wants to associate a 
mime type with a new app which must open in a terminal). For legacy apps which don't
have an associated desktop file, we just create a dummy one when it's needed.

user customization will be saved by adding attributes to the mime-type xml file
indicating whether the corresponding type/info was added/removed/modified by 
the user

FIXME: how to store app-specific info in the database? (to allow app writers to 
associate app-specific info to mime types) add custom xml attributes with proper 
namespacing ? Does it belong in a shared spec at all since by definition it will
be app-specific ?

Getting the applications associated with a mime type
====================================================

With the previously described extensions, there would be two ways to get the applications
associated with a mime type: by reading the MimeType field for all .desktop files, or
by looking up the xml file corresponding to the mime-type.

Actually we can't tell implementers to use these .desktop files: to find the apps 
associated with a given mime-type, implementers would need to parse all the desktop 
files, which is overkill. On the other hand, putting MimeType associations in .desktop
files is much more convenient for app writers to write and install a single .desktop file

=> mime-type info will be put in .desktop files, but will be processed by an 
update-mime-db-like program which will store the application/mime-type mappings
in the mime-type xml files

It is recommended that implementers don't load all the app/mime-type mapping at runtime
since it can be quite expensive timewise (especially because of the many small xml files
to parse). On the other hand, locating the appropriate xml file and parsing it when 
we need to look up the apps associated with a mime type shouldn't be too expensive. 
Moreover, the information for this mime-type can be cached for further use.

Generic Handlers
================

Some kind of generic handler would be convenient: A whole group of mime type can be 
associated to a generic "text editor", this will makes it much easier for user  
to change their default text editor.
This can be achieved by having some "generic" .desktop files which only contain a link 
to another desktop file => what happens if the generic text editor is uninstalled ?

-------------- next part --------------
This suggestions relies on two distinct groups of files. 