Proposal for a MIME mapping spec

[Mark McLoughlin]

Hi Jonathan,
	Proposal looks good, just some random comments :-)

On Wed, 2004-07-07 at 22:22, Jonathan Blandford wrote:

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

	I'm a tiny bit concerned about us continually overloading .desktop
files and that perhaps an app might want to be added to the mime mapping
but not the menus. Not a huge concern, its probably the best thing to do
overall.

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

	All other lists in .desktop files must be terminated with a ';' AFAIR.


> 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

	Is it entirely necessary to keep the .desktop suffix? Something like:

application/pdf: gpdf

	feels marginally more sane than:

application/pdf: gpdf.desktop

	OTOH, though, it could lead to the expectation that its a mime type to
executable mapping rather than mime type to .desktop file mapping.

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

	Power to the people ! :)

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

	Hmm, having a defaults.list in $XDG_DATA_DIRS/applications seems wrong
to me. I can handle mimeinfo.cache because its just a cache of parts of
the .desktop files. $XDG_DATA_DIRS/applications has always just felt
like a .desktop file repository.

	Also, I don't think it would be such a bad thing if "file.desktop" in
defaults.list in one prefix could end up being resolved against a
file.desktop in another prefix - i.e. you don't resolve the .desktop
file path until after you've read in all the preferred applications
lists and stripped out duplicates.

	So, I think we'd be better just having the file in
$XDG_DATA_DIRS/mime/defaults.list. That maps well to the fact the user
preferences are in $XDG_DATA_CONFIG/mime/defaults.list too.

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

	I don't get this last bit - do you mean a ~/.gnome2/mime/defaults.list
or ... ? If so, why?

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

	Ah, no ... Please, can we not just dump this if we don't think its
useful?

Thanks,
Mark.