mime-type/application association spec

[Christophe Fergeau]

Hi,

Since there didn't seem to have much activity to write a doc specifying
how mime-type/application associations could be handled in a
cross-desktop way, I decided to give a try at such a spec. Attached to
this email, you'll find a rough draft describing one possible way of
doing that. Keep in mind that it's a very preliminary draft whose main
goal is to start a discussion. 
There are probably many problems I didn't think about, it only talks
about GNOME specific stuff since I don't know how this problem is
handled in other desktop environments. However, I took various idea from
posts on this mailing list, so some parts of this document are probably
quite similar to what KDE is currently doing. 

So here is the document (it's also available from
http://cfergeau.free.fr/mime-spec.txt), any comment is welcome,

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.

It's not possible to associate a mime-type with an app which don't
have an associated .desktop file. Several .desktop files can be
concatenated in a single file to avoid having tons of files (FIXME: is
that compatible with the .desktop spec ?)



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, ...)). 

Need to be able to store lots of .desktop-like files in a single file (for 
efficiency reason and to replace gnome-vfs.applications)

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.

Store all mime types in a single file (efficiency reasons => 
multiple files = 50% slower (according to my totally unscientific tests))

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)

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 ?

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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.freedesktop.org/archives/xdg/attachments/20030610/23461b94/attachment.pgp