Shared-mime checking order

[Alexander Larsson]

On Wed, 2007-09-19 at 21:53 +0200, David Faure wrote:
> On Tuesday 18 September 2007, Alexander Larsson wrote:
> > On Tue, 2007-09-18 at 11:18 +0200, Patryk Zawadzki wrote:
> > > On 9/18/07, Alexander Larsson <alexl at redhat.com> wrote:
> > > Isn't just enough to check if either of them is the subclass of the
> > > second? If so, pick the more specific one.
> > 
> > That only works in the case of subclasses though, which might not always
> > be the case. Seems right to use that when its possible though.
> 
> Agreed. Do we also agree that this handling of multiple glob matches can be done right away
> inside glob-matching? No need to delay that to the "If several globs matches" resolution
> (after sniffing), IMHO.
> 
> So the new algorithm would be the one described with Alexander, with something like this prepended:
> Glob-matching should prefer derived mimetype over base mimetype, and longer matches
> over shorter ones. However if two globs of the same length match the file, and the two
> matches are not related in the inheritance tree, then we have a "glob conflict", which
> will be resolved below.
> "If several globs matches" in Alexander's algorithm really becomes "In case of a glob conflict", 
> i.e. two or more mimetypes with the same glob (like *.doc or *.ogg).
> 
> [Well technically you could invent a pattern like foo.* and *.doc, so that foo.doc matches both and
> you don't have a "longer match", but this is really border case (and would simply be handled
> as a "glob conflict" too).]

I think this sounds fine to me. There is only one more thing that I
think needs to be resolved. What mimetype do we pick on a glob conflict
if we only know the name (i.e. if we can't sniff). Should we add a
priority thing? Use the order in the files?

If we add priority to the glob tag (with some default if its not set) we
might be able to handle this in a backwards compat way by having the
priority affect the sort order in "globs" and "mime.cache".

> My problem is that I can't test the subclass case, README* is the only
> case of a glob match that has a * but not as the first character, so
> it's the only one that can give conflicts...
> So after implementing "take longest match", I see no way of testing
> "take subclass", since in the case of README.txt it is the longest
> match anyway... I could can data, but I also
> mean that we might not have a use case for it at the moment :)

I can't think of any case where its needed either, so maybe we should
drop that to lower complexity.

> OK. Anyone knows which other implementations of shared-mime-info
> around?
> xdgmime was mentionned, I don't know who knows it code well enough to
> modify it once we all agree on the spec changes, but the first
> question is: who else needs to approve those spec changes? Rox, I
> assume? Thomas Leonard CC'ed (see thread
> for more info, we covered "preferring globs over contents" before
> talking about glob conflicts).

I can try to handle xdgmime. Its what is used in Gnome.