[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: mime-type/application association spec



> 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.


> These are customisations for old applications that don't support the new
> system yet, yes? Ideally, the user should not have to modify the database.

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, ...


> 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.

Christophe

Attachment: signature.asc
Description: Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]