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, [email protected], sponsored by Qt Software @ Nokia to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
