Default Program | File Association

[Thomas Leonard]

On Thu, Jan 08, 2004 at 04:51:04PM -0800, Brenden T. wrote:
> I think there are people woking on this, but I like your ideas a lot.  
> I'd encourage you to go ahead and get your hands dirty.  More choices in 
> this area might improve the quality of the Linux desktop overall.
> 
> Some thoughts:
> 
> - File types are different than file associations.  Files have only one 
> type, e.g. "html", but may have more than one file association, e.g., 
> Mozilla, Konquerer, Emacs, vi, and gedit may all be capable of opening 
> "html" files.  There is one default association for each file type.  
> This is a simple one layer heirarchy; just zero or one single default 
> and zero or more other associations. No need for anything more complicated.

Yes. You still need overriding, of course (user prefs override sysadmin
prefs, which in turn override distribution prefs). But any decent config
system will do that anyway (including XDG_CONFIG_*).

> - GUIs aren't the only consumers of file types.  Apache can specify the 
> mime type of a file it serves up; it currently has it's own seperate 
> scheme for doing this, but a single solution that works for both GUIs 
> and servers may be good idea. It'll ensure future compatiblity and 
> reduce maintanence in the long run.

Yes, hopefully they'll use our system too. I think everyone is agreed that
the file associations stuff is a separate system built (partly) on top of
the existing database.

ie, the base MIME package we distribute contains no associations, and the
spec says nothing about it. A second spec defines suitable extension
elements (<desktop:can-edit-with>, etc) and software packages provide
their own associations to add to the db when they're installed.

A system running only apache would then have no association stuff at all.
If you installed Gimp, that would add a handler to the database. Whether
having separate output files for this makes sense (so apache doesn't have
to bother reading the association stuff at all), I don't know. However, I
think the *input* files should certainly keep it all together, and
update-mime-database can split it out however we please.

(in fact, apache would probably only care about the 'magic', 'XMLnamespaces'
and 'globs' files anyway, so the size of the image/gif.xml file wouldn't
matter anyway).

> - GUIs are the only consumers of file associations, that I can think 
> of.  This implies that a program to serve up file types, and a program 
> to serve up file associations may be two different things.

What if apache wants to generate thumbnails of some files when rendering a
directory? It might want to lookup the <thumbnail:generator> element that
ImageMagick installed.

Summary:

1. "*.html is text/html" is specified by a <mime:glob> element in the input,
   and output to the 'globs' file by update-mime-database.

2. "text/html is an 'HTML page'" is specified by a <mime:comment> element
   in the input, and output to text/html.xml by update-mime-database.

3. "text/html can be viewed with Firebird" is specified by a
   <desktop:viewable-with> element in the input, and output to text/html.xml
   by update-mime-database. This element is defined in a separate spec.

4. "text/html should by default be viewed with Mozilla" is handled by the
   configuration system, not by the MIME database.


1 & 2 are already done that way.

The exact format for 3 needs to be decided on. It could be output to a
different file, but I don't think we really want to do that.

4 is entirely separate, and requires us to spec the configuration system
first.


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk	tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1