On Mi, 2005-11-16 at 09:41 -0500, Matthias Clasen wrote: > 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.
No, that's not what I wanted to say. I think it is perfectly OK if not required to return XDG_MIME_TYPE_UNKNOWN in that case. It is just not possible to tell the actual MIME type from two identical globs, and predetermining one is just broken. > 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. Yeah, a function providing a maximum number of matches, also allowing to specify -1 for all matches would be appropriate. It should be exported to xdgmime.h. It would be a wrapper around the caches involved, of course. > > 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* ?) I agree with you, it is probably not worth the pain, since the performance impact can probably be measured in orders of magnitude, taking into account that we use a pretty fast algorithm for looking up simple globs and literals. > > 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. I'm appending a patch that just adds a paragraph on the multiple MIME type for one pattern case, and added comments about the acronym changes I made some weeks ago. Having a new shared-mime-info release within 4 weeks would be great, that should be enough time for final cosmetic changes, and translation updates. We're < 1.0, so why not release early and often? The last release is from 2004-03. A huge amount of bugs was fixed since then. Any major TODOs you'd like to point out? -- Christian Neumair <[EMAIL PROTECTED]>
Index: shared-mime-info-spec.xml =================================================================== RCS file: /cvs/mime/shared-mime-info/shared-mime-info-spec.xml,v retrieving revision 1.55 diff -u -r1.55 shared-mime-info-spec.xml --- shared-mime-info-spec.xml 1 Apr 2005 19:35:06 -0000 1.55 +++ shared-mime-info-spec.xml 16 Nov 2005 18:25:54 -0000 @@ -285,10 +285,26 @@ </para></listitem> <listitem><para> <userinput>comment</userinput> elements give a human-readable textual description of the MIME -type. There may be many of these elements with different <userinput>xml:lang</userinput> attributes +type, usually composed of an acronym of the file name extension and a short description, like +"ODS spreadsheet". +There may be many of these elements with different <userinput>xml:lang</userinput> attributes to provide the text in multiple languages. </para></listitem> <listitem><para> +<userinput>acronym</userinput> elements give experienced users a terse idea of the document contents. +for example "ODS", "GEDCOM", "JPEG" and "XML". +There may be many of these elements with different <userinput>xml:lang</userinput> attributes +to provide the text in multiple languages, although these should only be used if absolutely neccessary. + </para></listitem> + <listitem><para> +<userinput>expanded-acronym</userinput> elements are the expanded versions of the acronym elements, +for example "OpenDocument Spreadsheet", "GEnealogical Data COMmunication", and "eXtensible Markup Language". +The purpose of these elements is to provide users a way to look up information on various MIME types or +file formats in third-party resources. +There may be many of these elements with different <userinput>xml:lang</userinput> attributes +to provide the text in multiple languages, although these should only be used if absolutely neccessary. + </para></listitem> + <listitem><para> <userinput>root-XML</userinput> elements have <userinput>namespaceURI</userinput> and <userinput>localName</userinput> attributes. If a file is identified as being an XML file, these rules allow a more specific MIME type to be chosen based on the namespace and localname @@ -386,6 +402,13 @@ patterns of this form should be matched before other wildcarded patterns. </para> <para> +If a matching pattern is provided by two or more MIME types, applications +SHOULD not rely on one of them. They are instead supposed to use magic data +(see below) to detect the actual MIME type. This is for instance required to +deal with container formats like Ogg or AVI, that map various video and/or +audio-encoded data to one extension. + </para> + <para> There may be several rules mapping to the same type. They should all be merged. If the same pattern is defined twice, then they MUST be ordered by the directory the rule came from, as described above.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
