Am Dienstag, den 15.01.2008, 20:33 +0900 schrieb Charles Plessy: > Le Tue, Jan 15, 2008 at 12:08:35PM +0100, Daniel Leidert a écrit : > > > > What should be necessary? > > To check for the presence of words other than `HEADER' in the first line > of pdb files.
Well, I personally think, that we should *not* try to detect all broken formats, because companies/authors should better fix their software. So I try to make a compromise between the detection of a file with a broken format and broken files that are "broken too much". > > I would suggest or recommend chemical-mime-data. It also contains (as > > of version 0.1.95 IIRC) detection routines for KDE3 and > > libmagic/mod_mime_magic. > > I am not against, but I would like to read the opinion of other persons > about this. Basically the error messages wipe the whole screen whenever > a pacakage installs new mime types. Of course. However, I think the impact of renaming well established MIME type names without a wide consensus (much wider than just between Debian package maintainers) creates a bigger problem than using the unofficial primary type "chemical". I know, the situation is not the best atm. That's why I start discussions about it from tiem to time. You can find the latest at: http://www.nabble.com/Re:-SMILES-mime-types-p14229988.html. > Maybe a solution would be to patch update-mime-database to make it > accept chemical as a legitimate type: Or just output a warning once or do not output warnings for "x-" prefixed primary types (which would allow us to use x-chemical and add aliases to chemical/). I do not vote for hiding, that chemical is not official, but I understand, that it could be quite annoying to see the screen filled with warnings. A warning that appears once would be a good compromise IMHO. Maybe: Collect all warnings (represented by an integer) internally and then just output: The following warning was detected x times: Not a registered MIME type: chemical/foo. > --- update-mime-database.c.old 2008-01-15 20:25:19.000000000 +0900 > +++ update-mime-database.c 2008-01-15 20:25:43.000000000 +0900 > @@ -54,6 +54,7 @@ > "model", > "multipart", > "x-epoc", > + "chemical", > }; > > /* Represents a MIME type */ > > However, I do not know if it would have side effects… > > > > Most servers I know send .pdb files as chemical/x-pdb and not text/x-pdb > > Good to know, I was wondering how widespread the chemical/* types are. Very. Some weeks ago I discovered, that the W3C sends it Entity collection files as chemical/x-pdb, because of the .ent suffix. Now they fixed it. > > No, here I really recommend to stay with the historic name. I told you > > to not *create* new chemical/* MIME types (exception may be possible for > > "real" chemical file types, that are not application specific), not to > > rename existing ones. The latter will only create more confusion. > > OK. > > Are there plans to re-propose a RFC or to make the proposal evolve ? See the discussion at the link I gave you. > Because if > no new types are created, it will be difficult to argue for the adoption of > chemical/* as a standard. Creating a new RfC also means to define chemical/* types like text/plain or application/octet-stream were defined in the MIME RfCs. So there are currently a lot of chemical MIME types ... to be honest: much more than during the original RfC in 1994/5. But we should try to avoid to use chemical/* for every new chemistry related file format. We should be careful and use appropriate existing primary types if possible. For example: It doesn't make sense to name the gchempaint or gcrystal formats chemical/*, because they are application specific and therefor fit the application/ type much better. However, chemical/ was created, because exchangeable chemical file formats do not fit into the existing primary types. That was one of the reasons to propose chemical/*. So of course there might be other new formats, that also better fit into chemical/* than into other types (e.g. the newly written SMILES standard probably leads to such a format ... an alternative could be to extend the SMILES MIME type with an attribute). I hope, this helps to understand my point of view a bit better. Opinions are appreciated. Regards, Daniel
