Re: DynamicMimeTypes

[Alex Jones <alex weej com>]

On Thu, 2007-08-16 at 10:04 -0500, Shaun McCance wrote:
> On Wed, 2007-08-15 at 21:34 +0100, Alex Jones wrote:
> > 
> > The only difference between this and what I suggested is that you are
> > giving an explicit path to a script (what I was calling a "handler") to
> > be run. It's the same idea.
> 
> OK, I guess I don't quite understand where the handler fits in.
> 
> What I've seen in the past are proposals involving MIME groups,
> which could be specified in something like desktop entry files.
> These proposals always assumed that a plug-in will also install
> some sort of data to add a MIME type to a group.  This, to me,
> is a weakness, because there are things like File Roller which
> just depend on command line programs.  And I think there's very
> little chance we'll ever see programs like rar or zoo shipping
> with a data file to tell the desktop that File Roller can also
> handle their formats.  But a custom script shipped with File
> Roller could easily check for the existence of these programs.
> 
> Could you explain in a bit more detail how your handlers work?

Sure

You could just install executables under /usr/lib/$handlers

org.gstreamer.Audio
org.gnome.FileRoller

The former is installed by GStreamer and probes the GStreamer registry
to figure out what kind of file types it can play (as was said earlier,
this isn't that simple, but we can probably make a start with this
method.)

The latter is installed by File Roller and uses file roller's code to
decide what formats it can handle by seeing what programs are installed
and testing their capabilities.

Applications like Banshee may want to install their own handler that
itself calls org.gstreamer.Audio and org.helix-community.Audio (if it
exists, or use its own code to figure out what the helix backend's
capabilities are)

I'm just suggesting that we standardise these script locations and
names. We don't have to, I just thought it was nice. It's of little
importance, though.