Shared MIME-Info 0.12

Christophe Fergeau teuf at
Thu Sep 11 20:56:10 EEST 2003

> That's another way of doing it. I don't have any preference. Which would
> people prefer?
> The main advantage to having extra types is that aliasing becomes a
> special case of subclassing, whereas with an aliases file it's something
> completely different. But the aliases file would be quicker and smaller.

I don't have solid arguments against one or the other, but I tend to
prefer the extra types approach.

My two cents,


> > Would it be possible to add a paragraph to the spec along the lines of:
> > 
> > 	Whether a mime-type exists within the shared-mime-database may be
> > 	determined by the presence of a $XDG_DATA_DIRS/mime/<type>.xml 
> > 	file.
> > 
> > This is my understanding of the current behaviour, but I don't think
> > that it's explicitly mentioned and would be of use for applications
> > trying to work out whether they need to install a package to define a
> > particular type or whether it the user has it defined anyway.
> Applications should install their package file anyway. Even if the user
> already has a definition for application/foo, they may not have a French
> translation, the *.foo pattern, or the information that your application
> is capable of handling files of that type. Check the 'packages'
> subdirectory to see if your package is already installed.
> > If it's not already done, would it also be possible to wipe all the
> > generated xml files whenever update-mime-database is run
> Doesn't that happen anyway?
-------------- 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=2E?=
Url : 

More information about the xdg mailing list