Shared-mime checking order

[Alexander Larsson]

On Fri, 2007-08-24 at 16:15 +0200, David Faure wrote:
> On Friday 24 August 2007, Alexander Larsson wrote:

> > Ah, so we're actually doing the same thing. You're only sniffing when
> > there is no known extension, so the priority in that case is irrelevant.
> 
> Well let's not generalize. In 90% of the KMimeType use cases it's done correctly :-)
> But the "delayed mimetype determination" code for file managers doesn't really
> want to do magic on every file indeed. We have to find a rule for how to know when
> the mimetype could be refined by magic... which is quite related to my other post
> about conflicting results from extension matching (this is one case where we want to
> refine with magic later on). There might be more, like ogg if we make its rules low-prio,
> or pdf and ps.

Well, being a file manager guy, this is the main case i'm worried about
(that, and the file selector). The other uses rarely have the same
performance issues, so are not really a problem. But the file manager is
a very visible area, where we have to get the types right.

If we do sniffing when extension matching fails or causes a conflict,
and if we add the important conflicts to the mime database I think this
could work out ok though.

> > Do you do this even when deciding mimetype for picking app to open the file in?
> 
> In that case we should really make sure that the mimetype determination is correct,
> so we should use the full spec-compliant matching (including preferring high-prio rules).
> There might be a bug there in the current kde4 code, but that's a detail :)

This is a bit iffy. It means you display a certain kind of icon, so the
user expects a certain app to start, but then another app unexpectedly
starts. (Thus the ugly nautilus warning dialog...)

This is my main problem with hi-priority sniffing. It either causes very
bad performance behaviour in the file manager, or it adds user-visible
confusion as to the type of some files.

I personally prefer to drop the hi-prio sniffing, and use sniffing only
on conflicts and on extension match failure. This way you get only one,
well defined, usable everywhere, canonical type (well, there is also the
first-scan "fast mimetype", but you never open a file based on that). It
also means that any user problem with file types is solvable by the user
(just rename the problematic file).