MIME info spec: Handling containers/multiple MIME types per glob pattern

[Matthias Clasen]

On Wed, 2005-11-16 at 15:15 +0100, Christian Neumair wrote:
> Matthias Clasen wrote:
> >The patch that I posted a few weeks ago only sniffs if there
> >are multiple identical globs that match, which is a fairly rare
> >case in the current shared-mime-info data (only, .pot and .pcf,
> >if I remember correctly).
> >  
> Sounds like excellent material. It is available under [1], just for the 
> reference.
> XDG would return XDG_MIME_TYPE_UNKNOWN if the fopen fails, and multiple 
> MIME types specify identical matching glob patterns, right?

Hmm, you are right. It might be better to return the first matching
glob's mimetype in that case.

As you said in an earlier mail, it might also be valuable to expose the
multiple glob matches via the api in some way, so applications can
decide on their own how to handle this case.

> While this still wouldn't work for the more complex matches "README*", 
> "*EAD*", "*DME", it takes care that container formats (ogg, avi) or glob 
> patterns used by multiple mime TYPES "*.pot" friends play nicely with 
> Nautilus. Since KDE AFAIK currently does the same (glob matching, 
> contents for particular container MIME types only), it would also be 
> useful for them.

I think only exaclty identical globs should be considered as duplicates
(ie if both *.gz and *.tar.gz match, the longer one is better), and
anything but suffix patterns are too rare to worry about (what mimetype
could be interested in matching *EAD* ?)

> It would be nice to get this in, and to get some feedback from potential 
> XDG MIME API client projects. Are you willing to patch write a spec 
> patch yourself, or should I tackle this?
> 

If you write a spec patch, I would be happy to review it. I think the
sections about recommmended matching order and the cache file format
descriptions need modifications.

Matthias