mime-type/application association spec

[Jeroen ten Berge]

> > You shouldn't be loading all the files. The database is 
> split so you only
> > load the bits you need, as you need them. This should be 
> much faster than
> > loading the whole database.
> > 
> 
> That makes sense. Though that might make monitoring changes in the
> database more difficult.
That's where you need triggers and stored procedures :)

> I don't understand what you mean here. This document is an attempt to
> specify how we could store in the mime database things like "emacs, vi
> and jedit can be used to open C source files, and the current 
> user wants
> to use emacs to open those files". This part of mime handling must be
> user modifiable, an user will want to change the default app used to
> open some mime type, he will want to add his favourite app if it's not
> there yet, ...
Absolutely !

> > There was a suggestion of inheritance. Eg 'image/svg is-a 
> text/plain'.
> > 
> > Possibly however, the two generic rules 'text/* is-a text/plain' and
> > '(^inode)/* is-a application/octet-stream' cover all the 
> useful cases.
> 
> I'm not sure this is good enough. What I have in mind is to be able to
> specify a default handler for audio files (ogg files are 
> application/ogg
> for example, so we can't use audio/* there), or for "source 
> code files"
> or things like that. I don't really want to specify "standard"
> categories there, but leave the opportunities to desktop 
> environment to
> have generic text-editor/audio player/... if they wish to.
Yes, don't make it to harsh to implement, i think winblows hadles this pretty well, you can select the default open action for a certain mime-type, as well as add a lot of optional editors for a mime-type :
Mimetype:       Action:       Command:
images/SVG      Open          Adobe SVG Viewer
images/SVG      Edit          Notepad
images/SVG      Edit          Adobe Illustrator
images/SVG      Edit          Vector

L8r,
Jeroen.