Proposal for a MIME mapping spec

[Ghee Teo]

Hi,

    Bravo! This is some good writeup here!

    Once thing which it does not mention though is backwards 
compatibility. What happen to apps which have been created the desktop 
before this spec but due to some reasons, these desktop files cannot be 
updated according to this new spec, how will they behave?

-Ghee



Jonathan Blandford wrote:

>Hi,
>
>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:
>
>Executive summary:
>==================
>
>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:
>
>MimeType: application/pdf
>
>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.
>
>Search Path:
>============
>
>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.
>
>Caching:
>========
>
>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
>$XDG_DATA_DIRS/applications/mimeinfo.cache
>
>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:
>
>  application/x-foo=foo.desktop;bar.desktop;
>  application/x-bar=bar.desktop
>
>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.
>
>Preferred Applications:
>=======================
>
>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:
>
>mime/type:file.desktop
>
>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
>little complicated.
>
>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.
>
>Other Issues:
>=============
>
>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.
>
>What's Next:
>============
>
>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?
>
>Thanks,
>-Jonathan
>
>_______________________________________________
>xdg mailing list
>xdg at freedesktop.org
>http://freedesktop.org/mailman/listinfo/xdg
>  
>