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

Re: mime-type/application association spec

On Wed, Jun 11, 2003 at 01:24:12PM +0200, Christophe Fergeau wrote:
> > 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.

Changes will always update the globs file, so it's fairly easy to detect.
You still have to reload everything, but the database should be very
static (only changed on software installation) so it shouldn't matter.

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

The MIME page suggests the first, but explicity rules out the second use.
It's possible to store preferences there, of course, but it's not designed
for that and it would be very inefficient.

We need some kind of shared config system for the various desktops anyway,
and configuration information should go there (the first step towards this
is XDG_CONFIG_* in the base dir spec).

All that's actually required is an $XDG_CONFIG_DIRS/mime/handlers file
listing the user's preferences. No need to go rebuilding any databases
from hundreds of source files on every change...

(in ROX, we actually store one file or symlink for each type, so you can
do 'exec .../MIME-types/text_plain "$1"', etc, but other systems should
work fine too)

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

You can't specify ogg->audio, because ogg isn't always audio. Otherwise,
it would be in audio/* in the first place.

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

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