Re: Inconsistency between mime-support, shared-mime-info and file for PHP files media types.
Le Fri, Aug 31, 2012 at 07:37:17PM -0700, Russ Allbery a écrit : There was a previous discussion on debian-devel about this, during which I posted a scetch of an implementation strategy for converting the XDG MIME files to the mailcap syntax. Someone else then fleshed out that script a bit more, and I thought submitted it to the BTS, and then there was some subsequent discussion in the Technical Committee in the context of the evince application/pdf MIME registration that I thought indicated someone was working on that further. It may be that I had misunderstood. Now I understand :) There are two FreeDeskotp (XDG) works relevant to media (MIME) types. - The menu entry specification (http://standards.freedesktop.org/menu-spec/latest/), where a program can declare that it can operate on a given media type. This is the one that was recently discussed, and indeed mime-support in experimental is a first step into de-duplication of information between packages desktop menu entries and mailcap entries. - The shared MIME info database and its specification (http://freedesktop.org/wiki/Software/shared-mime-info) (http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html), where media types are associated with file suffixes. Some of these associations stem from the media type registrations to the IANA, which in the mime-support package are reflected in /etc/mime.types. The shared MIME info database is distributed in Debian's package shared-mime-info, and in theory, this package would be able to produce and distribute /etc/mime.types as well. In practice, I think that the unregistered types should be compared first. I hope I (or others) will find time to submit a patch to the Policy in the next months, to describe shared-mime-info in the same way as mime-support. There is a third provider of media types, the file package. I think it would be good to eventually have a solid description of how media types are inferred in Debian systems, and which packages operate on which installation profiles (mime-support and file are of standard priority, while shared-mime-info is optional). By the way, I completely agree to the comment you made to Josselin. The packages providing the minimal functionality are not a hindrance to more advanced solutions. I hope that the recent upload of mime-support to experimental is a clear enough message. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120901060852.ga22...@falafel.plessy.net
Re: Inconsistency between mime-support, shared-mime-info and file for PHP files media types.
Le Thu, Aug 30, 2012 at 12:48:01AM -0700, Russ Allbery a écrit : That's the reason why people are pursuing generating the metamail-style database *from* the XDG MIME specification so that we can use a richer specification in as many places as possible but fall back on the previous standard for applications that still use it. Hi Russ, I would be interested to have pointers to such projects. For the registered media types, in my undestanding both mime-support (or its equivalents in other distributions) and shared-mime-info (through its XDG upstream) are tracking IANA's definitions, which is a duplication of work that I would be glad to see resolved. The biggest hurdle is probably that the divergence in regard to the unregistered types, and the potential side effects of changes if a merger happened. Have a nice week-end, -- Charles -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120901005410.ga21...@falafel.plessy.net
Re: Inconsistency between mime-support, shared-mime-info and file for PHP files media types.
Charles Plessy ple...@debian.org writes: Le Thu, Aug 30, 2012 at 12:48:01AM -0700, Russ Allbery a écrit : That's the reason why people are pursuing generating the metamail-style database *from* the XDG MIME specification so that we can use a richer specification in as many places as possible but fall back on the previous standard for applications that still use it. Hi Russ, I would be interested to have pointers to such projects. For the registered media types, in my undestanding both mime-support (or its equivalents in other distributions) and shared-mime-info (through its XDG upstream) are tracking IANA's definitions, which is a duplication of work that I would be glad to see resolved. The biggest hurdle is probably that the divergence in regard to the unregistered types, and the potential side effects of changes if a merger happened. Well, perhaps I'm confused, since I thought that was part of what you were working on! :) There was a previous discussion on debian-devel about this, during which I posted a scetch of an implementation strategy for converting the XDG MIME files to the mailcap syntax. Someone else then fleshed out that script a bit more, and I thought submitted it to the BTS, and then there was some subsequent discussion in the Technical Committee in the context of the evince application/pdf MIME registration that I thought indicated someone was working on that further. It may be that I had misunderstood. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4qmjwo2@windlord.stanford.edu
Re: Inconsistency between mime-support, shared-mime-info and file for PHP files media types.
Le jeudi 30 août 2012 à 00:38 +0200, Christoph Anton Mitterer a écrit : On Thu, 2012-08-30 at 07:16 +0900, Charles Plessy wrote: A type is a subclass of another type if any instance of the first type is also an instance of the second. For example, all image/svg files are also text/xml, text/plain and application/octet-stream files. Subclassing is about the format, rather than the category of the data (for example, there is no 'generic spreadsheet' class that all spreadsheets inherit from). This sounds highly interesting... I wonder whether this works gracefully together with all standards (but at a first short glance, I wouldn't see why not)... and what it needs to make applications aware of it. All applications implementing the XDG MIME specification (e.g. through GIO or kdelibs) get the benefit of such features (and others such as aliasing). Yet people keep screaming that mime-support is awesome and don’t want to drop it. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346312226.3479.310.camel@pi0307572
Re: Inconsistency between mime-support, shared-mime-info and file for PHP files media types.
Josselin Mouette j...@debian.org writes: All applications implementing the XDG MIME specification (e.g. through GIO or kdelibs) get the benefit of such features (and others such as aliasing). Yet people keep screaming that mime-support is awesome and don’t want to drop it. Please don't distort other people's opinions to make rhetorical points. We've had multiple discussions on this topic, and very few people were expressing the opinion that mime-support was better than the XDG MIME system, let alone awesome. They were, rather, pointing out that they use a bunch of applications that don't USE the XDG MIME system, and therefore its theoretical benefits aren't actually useful to them right now. I think there's general agreement that in an ideal world everything would use the XDG MIME system or something equally rich and not the old metamail system. But we can't fix every piece of software that we use overnight, particularly given that the conversion from a metamail-style system to the XDG MIME system is not exactly a trivial endeavor for any piece of software that uses MIME heavily. That's the reason why people are pursuing generating the metamail-style database *from* the XDG MIME specification so that we can use a richer specification in as many places as possible but fall back on the previous standard for applications that still use it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bohsstvy@windlord.stanford.edu
Inconsistency between mime-support, shared-mime-info and file for PHP files media types.
[Copy sent to maintainers of mime-support, shared-mime-info, file and php5, as an invitation to participate to the discussion.] Le Sun, Aug 26, 2012 at 01:27:51PM -0700, Ben Hutchings a écrit : On Sun, 2012-08-26 at 19:55 +0200, Christoph Anton Mitterer wrote: With things like SVG it's quite tricky,... SVG has application/ (as most XML types will have)... the reason probably, that it's interpreted into drawing commands. I think the reason is that SVG is not usually read or written using generic text tools. Similarly the X bitmap type is image/x-xbitmap and not text/x-xbitmap, even though it can be read as ASCII text. (A new top-level type like 'vector' would have been better though.) Hello everybody, note that to solve the problem caused by interpreted files being sometimes seen as application (or image) and sometimes seen as plain text, the FreeDesktop Shared MIME-info Database specification introduces a new concept, subclassing. A type is a subclass of another type if any instance of the first type is also an instance of the second. For example, all image/svg files are also text/xml, text/plain and application/octet-stream files. Subclassing is about the format, rather than the category of the data (for example, there is no 'generic spreadsheet' class that all spreadsheets inherit from). http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html#subclassing In the case of unregistered media types, nothing prevents parallel systems to report inconsistent information. This is what happens with PHP. * mime-support does not associate .php files with media type anymore, although text/x-php and application/x-php have been proposed. * shared-mime-info has application/x-php as a subtype of text/plain. * file has text/x-php for files that start by ?\n or ?php. If members of the upstream PHP community read this, how about standardising throuhg the IANA, or if this was alredy proposed and rejected, at least through a recommendation on the PHP web site ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120829221641.gb2...@falafel.plessy.net
Re: Inconsistency between mime-support, shared-mime-info and file for PHP files media types.
On Thu, 2012-08-30 at 07:16 +0900, Charles Plessy wrote: A type is a subclass of another type if any instance of the first type is also an instance of the second. For example, all image/svg files are also text/xml, text/plain and application/octet-stream files. Subclassing is about the format, rather than the category of the data (for example, there is no 'generic spreadsheet' class that all spreadsheets inherit from). This sounds highly interesting... I wonder whether this works gracefully together with all standards (but at a first short glance, I wouldn't see why not)... and what it needs to make applications aware of it. * file has text/x-php for files that start by ?\n or ?php. Whew... can't that lead to false positives? (and shouldn't we intentionally not-support ? *G*) If members of the upstream PHP community read this, how about standardising throuhg the IANA, or if this was alredy proposed and rejected, at least through a recommendation on the PHP web site ? Well... going through the IANA processes is like fighting windmills... I once registered some port numbers and that felt like an decade-long process ;) Guess that's what many communities fear, as well as the fact that IANA demands usually lot of specs and definitions. But of course it would be awesome if we get official MIME types and content encodings for all those wide spread file types (tar, ar, deb ;-) gazillions of image files, etc. pp. ) and encodings like (xz, bzip...) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
