Re: MIME type for PDB files.
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
Reply to: