mime-type/application association spec

[Christophe Fergeau]

> Yes, there seems now to be a format for the mime-types but not how to 
> associated applications to mime-types. I suppose to do it similar like KDE 
> does it. The MimeType Key is alreay in the Desktop specification, so we have 
> no problems here.

I must admit I haven't read the .desktop spec really carefully, I should
reread it once or twice.

> 
> can_open_multiple_file: Why do we need that? Take a look at the exec 
> parameters you have %f, a single file name, and %F an list of files names.
> 

As I wrote in the file, it's not completely obvious, people who write
.desktop files for their app may miss it. Nothing which can't be fixed
with a bit of doc though :)

> uses_gnome_vfs: Again why? Backward compatibility?
> 

As I said in the file, this one is not really meant to go in a shared
spec, but rather an extension that gnome would need to add. gnome is
currently using this to indicate that an app is using gnome-vfs, which
means this app can open any url scheme known to gnome-vfs (the list of
supported schemes can't be known when the app is installed or written).

> supported_uris: Interesting topic to think about, but I don't think it has to 
> be in this specification, mainly this uris are all opened by 
> nautilus/konqueror, so we should think about a specification for this uris, 
> but not to add them to this standard.

I don't understand what you mean there :) This entry was once again
copied from what gnome is doing, this is used by apps which aren't using
gnome-vfs to tell which kind of uri they can open (eg, galeon would
declare file: http: and ftp:, wget would put http: and ftp: there, ...)

> 
> >Store all mime types in a single file (efficiency reasons => 
> >multiple files = 50% slower (according to my totally unscientific tests))
> Maybe it's faster, but it's difficulter to maintain, so I think we do not need 
> this file at all. The priority is done via the InitialPreference Parameter I 
> think.

more difficult to maintain ? this file would be auto generated, in
exactly the same way that the mime type tree is built in the shared mime
spec (using some prog whose name I forgot). Though the approach
suggested by Thomas Leonard of only loading those files on demand is
probably enough.

> 
> So all in all I would propose to standarize the KDE extensions to the .desktop 
> format. But why standarize them, they are already standard, but this is not 
> widely known ;D

I must reread this spec, it seems I missed some parts of it ;) I didn't
see this InitialPreference parameter, and I was a bit confused by the
MimeType explanations, I thought this field was deprecated, or limited
to .desktop files not describing an app, or something like that.
Hopefully I'll understand all of this better tonight ;)

Even if the .desktop spec contains most of what is needed, we still need
a way for the user to add/remove helper apps for each mime type, and to
specify how these changes should be saved. 
A way for app writers to add info to mime-types would also be nice imo
(for example, a web browser may want to set a "always save to disk files
with this mime type without asking anything"). These are per-app
settings, so one may argue it's pointless to have that in a shared spec,
but imo it would be cleaner if everyone put their customizations in the
same place.
With this "only use .desktop files to store mime associations" approach,
I'm also a bit concerned with speed: there are potentially hundreds of
small files to parse at once the first time you want to know "which apps
are associated with this mime-type".

Christophe
-------------- 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/20030611/3f37a6bf/attachment.pgp