[RFD] Debian's mime support
Debian's mime support has two flaws which are nearly fatal. First is that
very few packages which could provide mime data for the types they support
actually do so. Second is that very few programs that do anything with
mime types use mime.types and mailcap anymore. This is understandable
since those unix dinosaurs are largely useless in modern applications such
as GUIs and the like. They were designed to tell your mail reader how to
show you what's in an attachment and frankly that's all they're good for.
We can do mime a lot better. And we should.
Gnome's Mime System
-------------------
Having to play with it so much lately, I've gotten fairly comfortable with
Gnome's mime handling. It works well, but has limitations of its own.
And those limitations aren't likely to be fixed by the Gnome VFS mime
support either, since they probably were never considered. Perhaps if
someone reading this message is interested in fixing that, it might
change.
Gnome provides /usr/share/mime-info which contains *.keys and *.mime
files. Here are a few entries from /usr/share/mime-info/gnome.mime:
text/css
ext: css
text/x-makefile:
regex: [Mm]akefile
text/x-readme:
regex: README.*
text/x-C++
ext: cc C cpp
A .mime file contains only a list of mime types. Note the :'s which some
entries have and others don't. It's allowed but not required, ick. And
you can use regex to specify a filetype - very handy (and not allowed in
mime.types!)
Here's a look at /usr/share/mime-info/eeyes.keys, which is nice and
simple:
image/*:
open=eeyes %f
view=eeyes %f
As I said before, this works well for Gnome, but it doesn't fit the needs
of Debian. Multiple definitions of a mime type appear to call for the
first type found being used. In other words, if there were a default.mime
with a reasonable default for image/jpeg bearing the usual extensions, it
would royally suck if some abc.mime defined image/jpeg as having .xyz for
an extension and the first match was taken. You could attempt to merge
the data (someone tell me if Gnome does) but still, it's a problem.
Another problem is that not all applications support regex file matching.
In fact, a lot don't, so if we support that in Debian, we'll have to
support ignoring such types for legacy apps that don't support their use.
The last problem is the handlers, which also appear to be first come,
first serve. If my preferred image viewer were qiv (it is) and you
consider an ascii sort, eeyes will get the open and view actions, gimp
would get the edit action. (in truth, neither gimp nor qiv provide mime
data to Gnome or Debian..)
The Nifty Solution
------------------
Debian needs to revamp mime-support. I suggest we take ideas from menu
and from dpkg's alternatives system. Packages should provide a file in
/usr/share/mime/<package> listing what types they handle and how. A file
named /usr/share/mime/<package>.types could be used to list mime types and
identification.
I suggest we use text files arranged in rfc-822 header-style stanzas.
Here is a good example of how the entry for eog (the standard Gnome
graphics viewer these days) would look:
Mime: image/*
Priority: 20
Environment: Gnome, X11
Open: qiv %f
View: qiv %f
A .types file including html would look something like this:
Mime: text/html
Ext: html, htm
Some method of backward compatibility is of course essential, but it's
reasonable to figure out at least whether the environment is X11 or not
and what the Open command would be. View and Edit would have to be left
out since they're not supported by legacy mime in Debian. A default
priority would have to be assumed.
New packages could provide Regex or Magic (in theory you should be able to
provide all three, but why?) in their .types files, and priorities could
be used to figure out what gets preferred by default, with user overrides.
The update script should of course create the legacy mime.types and
mailcap files, but should do so with method scripts ala menu. Other
programs with other methods to teach them about mime types should provide
scripts to use them. At some point it'd be real nice though if the
primary method performed by the script were to create a hash of the data
for programs to take advantage of, creating a new standard not centric to
Debian.
As for Environments, so far I've come up with console, terminal, X11,
Gnome, KDE, emacs, www, and java. www would essentially mean feed it to
netscape or mozilla or something - application/x-url comes to mind.
Things passing files off to mime handlers would have to choose the highest
priority handler of the environment they want. Gnome for example would
look for a Gnome app before an X11 app before a terminal app and would
ignore console-requiring apps all together.
Known Issues and Unresolved Questions
-------------------------------------
Doesn't this mean that methods have to stay in sync with the scripts that
use them? Yes. dh_compat shows a solution to this.
Should there be a central file included with the mime scripts defining
lots of standard types? Good question - I don't have a good answer,
there are pros and cons to the idea.
A way to make decisions about overrides to default priorities and locally
installed programs and the like is easy at the system-wide level, but at
the user level there's no easy way to do it. Menu currently faces the
same problem.
Even if this gets done, lots of packages will still have incomplete or
non-existant mime data. Bugs will have to be filed (complete with the
mime data to add, since it's trivial to do if you care to do it..)
Well, how's it sound? Reasonable? Workable? Usable? Should it be done
as a Debian thing or should it be done outside of Debian specifically as
an attempt to do away with mailcap and then integrated later? Anyone else
interested in working on this? Anyone from the Gnome or KDE projects want
to look into using this kind of generic system upstream? That would make
users better able to override the defaults, certainly.
--
Joseph Carter <knghtbrd@debian.org> GnuPG key 1024D/DCF9DAB3
Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC
The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3
NEW YORK (CNN) -- Internet users who spend even a few hours a week online
at home experience higher levels of depression and loneliness than if
they had used the computer network less frequently, The New York Times
reported Sunday. The result ... surprised both researchers and
sponsors, which included Intel Corp., Hewlett Packard, AT&T Research and
Apple Computer.
Reply to: