Shared MIME-Info 0.12

[Geoff Youngs]

On Fri, Aug 29, 2003 at 02:25:17PM +0100, Thomas Leonard wrote:
> On Fri, Aug 29, 2003 at 02:32:05PM +0200, David Faure wrote:
> [...]
> > (except that we currently lack a few features like magic overriding
> > extensions for some mimetypes).

> I've added the missing text to the recommended checking order:

> 	"If no explicit type is present, magic rules with a priority of 80
> 	or more should be tried next. These rules have a very low
> 	false-positive rate."

> I think some method to handle deprecated type names is the main
> missing feature. Something like:

>       <mime-type type='audio/x-midi'>
> 	<type-renamed new_name='audio/midi'/>
>       </mime-type>

> If noone suggests better names, I'll add it...

Why create "non-existant" entries?  Wouldn't it be easier to use
something like the following?

	<mime-type type='audio/midi'>
		<alias type='audio/x-midi'/>
		... rest of midi info ....
	</mime-type>

And then have an aliases file along the lines of the globs file which
can be used to map recognised types to used types?

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.

If it's not already done, would it also be possible to wipe all the
generated xml files whenever update-mime-database is run so that there
are no remaining "ghost" entries for types which were defined in the
past, but which are no longer?  Such as applications which symlink their
package info into the mime/packages dir and are then uninstalled.

Thanks,


Geoff.