Fwd: Re: main extension for a mimetype

[Alexander Larsson]

On Wed, 2009-04-08 at 11:56 +0200, David Faure wrote:
> On Wednesday 08 April 2009, Alexander wrote:
> > I think the reason the globs are a per-glob map is that when the globs
> > are stored in the mime.cache file some of the items (suffixes, literals)
> > are stored sorted.
> 
> Ah. I don't know anything about mime.cache ;-)

You use a similar thing, right? ksyscoca? How does that work, is it also
mmaped by apps, or is it an ipc thing?

> > I can have a go at fixing this. However, there is an issue here with the
> > ordering. There is a given order for the patterns in the xml files, but
> > the globs file is sorted by glob weight. With a stable sort this would
> > only be a problem if a glob that is not the main extension for the file
> > has a larger weight. Is this a problem?
> 
> Hmm. The point of glob weights is to choose between two mimetypes that use the same glob;
> not to order the globs of a single mimetype. But glob weights have that side effect, though, indeed.
> Let's see. Hmm. Let's say we have,
> 50:app/foo:foo.*
> 50:app/bar:*.gbar
> 10:app/bar:*.bar
> 
> The lower glob of 10 is there so that "foo.bar" is seen as app/foo rather than as app/bar.
> If we still want to say that *.bar is the main extension for app/bar rather than *.gbar,
> then we have a problem. But an easy solution too: changing the weight of *.gbar to 10 too,
> which only becomes a problem if that glob also conflicts with another glob somewhere else...
> 
> Given that we only have one use of glob weights right now this seems rather unlikely,
> but if we want to be on the really really safe side, we could simply... ah yes, we could
> preserve the <glob> elements in the generated app/bar.xml file? Then I could just
> read the preferred glob from there, and globs2 can keep its hash-based implementation?

Yeah, I was thinking about that too. Its probably a better idea than
overloading the glob file order.