Proposal for a MIME mapping spec
jrb at redhat.com
Thu Jul 8 00:22:46 EEST 2004
At GUADEC, Waldo Bastian, Dave Camp, Alex Larsson, Zack Rusin, and I met
to discuss putting together the final part of the MIME spec. In
particular, we discussed the mapping of applications to MIME-Types. We
went through what we wanted that spec to do and put together a proposal.
Our approach was fairly simple and (hopefully) non-controversial. It
builds off of the original spec as proposed for desktop files five years
ago. I'm working on a patch to both desktop-entry-spec.xml and
shared-mime-info.xml, but am including a description now for discussion:
Each application installs a .desktop file that lists the MIME Types that
it can support. A program is then run which caches a mapping of MIME
Types to desktop files. Additionally, a vendor provided file lists the
preferred application for a given MIME Type. Each user on the system
can override this preference.
More Detailed Description:
Every application installs a .desktop file as described in the current
spec. The 'MimeType' field in that desktop file includes a list of
every MIME Type that that application can handle. For example, a PDF
viewer could have the following entry:
Applications that can handle multiple MIME Types would list all of the
ones it can handle in a ';' separated list. It is expected that for
some applications this list could get longish. Additionally, there
should be no priority for MIME Types in this field, or any form of
priority in the desktop file.
We will use the basedir search path ($XDG_DATA_DIRS) to search for
applications. The relevant directory is $XDG_DATA_DIRS/applications/,
and the other directories defined in the menu spec.
To make parsing of all the desktop files less costly, we will provide an
'update-desktop-database' program that will regenerate a database file.
The concept is identical to that of the 'update-mime-database' program
in that it lets applications avoid reading in (potentially) hundreds of
files. It will need to be run after every desktop file is installed.
One cache file is created for every entry in
$XDG_DATA_DIRS/applications/, and will create a file called
The format of the cache mirrors that of the desktop file, and is just a
list of mime-types to desktop files. Here's a quick example of what it
would look like:
Each MIME Type is listed only once per cache file, and the desktop file
is expected to exist in that particular directory. That is to say, if
the cache file is located at /usr/share/applications/mimeinfo.cache,
bar.desktop refers to the file /usr/share/applications/bar.desktop.
There is also a preference list to determine preferred application of a
given MIME Type. It defines the 'default' application to handle a given
MIME-Type. It has the same format as the cache list, except that each
entry is limited to only one item:
If a mime type is listed multiple times (either in the same file, or in
another file further down the search path), the latter mention wins. If
a listed file doesn't exist, or is precluded through the 'OnlyShowIn' or
'NotShowIn' files, they should be ignored. This means that applications
will have to keep a history of the preferred applications that they run
into, so that if the top desktop file for a given MIME Type isn't
available, the second one can be tested, etc.
It is also worth noting who this mechanism is defined for. It is
primarily intended for use by distributors/sysadmins to provide a sane
set of defaults for their users. Additionally, users themselves can use
this mechanism to override the user defaults. We intentionally don't
provide a way for application authors themselves to list themselves as
the default for a given type, as we felt that that cannot work.
Path Resolution For Preferred Applications:
The order in which the preferred applications list is determined is a
The defaults are first read in
$XDG_DATA_DIRS/applications/defaults.list. It is expected that these
defaults are set solely by the distributor of the system. Then, a
$MIME_PREFS_LIST environment variable is checked for other preferred
applications. This is expected to be set by a sysadmin providing their
own defaults. Additionally, each desktop should prepend its own
defaults to this variable. Then, $XDG_DATA_CONFIG/mime/defaults.list is
checked for user-specific defaults. Finally, it is expected that each
desktop will have their own (optional) user-specific desktop file.
The current desktop file lists 'Actions' as a possible entry. We
decided against including actions in this specification. It is
currently left for desktop projects to implement in their own fashion.
The first thing we need to do is discuss this on the list, and come to
some form of consensus. I'm hoping that this approach will be largely
non-controversial, as it is similar to what was proposed five years ago
and close to what KDE currently uses.
I'm then planning on writing up a patch for the desktop-file spec to
modify it to have these changes in it.
Finally, I'm going to need to write 'update-desktop-database', unless I
can convince someone else to do so.
Comments? Questions? Concerns?
More information about the xdg