Fwd: Re: main extension for a mimetype

[David Faure]

On Wednesday 08 April 2009, Alexander Larsson wrote:
> 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?

Yes, ksycoca is mmap'ed by apps (or uses shared memory on Windows).
If mmap or shared-mem fails, we fall back to a plain file (seeking and reading
into it at specific offsets just like we do with the mmap'ed data).

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

Yeah, seems much simpler. And no overhead for me since kbuildsycoca is already parsing
the xml files anyway (to read the <comment> tags).

BTW with reference to our other discussion, this means <glob> and <glob-deleteall>
nodes should both be written out into the generated .xml files, so that we don't end
up using a deleted glob as the main extension :-)

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).