(The title refers to Single point of failure, which vaguely relates to the issue at hand.)
I was talking with Ian (Amarok) and Pino (Okular) tonight, as I fixed a few more mimetypes in xine-lib, about shared-mime-info.
The SMI package, originally written for GNOME, but nowadays also used by XFCE and KDE4, contains an XML file which contain the list of mime types, the extensions they can take and a few magic numbers to identify the mimetype of a given file.
Having a shared package is quite a good idea actually, and as shared-mime-info is extensible by adding an extra xml file (like OpenOffice does), it adds flexibility to be able to change the data in one place to fetch it from everywhere.
But, one tool that is not using this data is the main consumer of similar data: file(1). The file implementation we use at the moment has its own data files to discover the type of files, it does not use shared-mime-info.
So if anybody would like to cut his teeth with a new application, I suppose it would be at least a nice proof of concept to have a 100% compatible file(1) implementation – libmagic included – which uses shared-mime-info database for gathering the data.
I’m just not sure if shared-mime-info contains enough data to implement that, as file(1) reports a few extra information about the files, like the version they implement (for audio files for instance). It would be nice, though, if we could do that, as that would mean that we’d have a viable single source for such data, which is a good thing as you can share it between even widely different software.
I could not agree more, such a unification could be great.It can make programs like thunderbird, firefox, any program that need to cope with files they cannot handle behave more nicely and provide one or more alternatives program that can visualize/modify the file in object.At the moment for example kde (3.5) recognition of mimetipe, and association is good but not shared [1] with all the applications used in a normal desktop environment.[1] there are hack that can make things better but are hacks indeed
I got inspired by this post to try my hand at doing a SMI-powered file(1) implementation. It’s still very much a work in progress but one can find it here.