Re: [hatari-devel] disk image mime-types (was: hatari-ui icon)

[ Thread Index | Date Index | More Archives ]

Am Sat, 6 Dec 2014 11:08:59 -0700 (MST)
schrieb David Savinkoff <dsavnkff@xxxxxxxxx>:

> ----- Thomas Huth wrote:
> > Am Fri, 14 Nov 2014 20:56:16 +0100
> > schrieb Thomas Huth
> > Actually, it does not seem that hard to register official
> > mime-types. I am currently considering to have a try to register
> > the mime-types for .MSA and .DIM images as a start (and if that
> > works out fine, later for the other disk image types, too).
> > 
> > A question to everybody: How should the mime-types (also called
> > media types nowadays) be named? My current suggestions are:
> > 
> > For .MSA:
> > 
> > - application/vnd.msa-disk-image
> > - application/vnd.magic-shadow-archive
> > - application/vnd.magic-shadow-archiver-disk-image
> > 
> > For .DIM:
> > 
> > - application/vnd.dim-disk-image
> > - application/
> > - application/
> > 
> > Any preferences or other suggestions?
> > 
> >  Thomas
> > 
> Hi, I'm all for mime-types, however, I've got more questions
> than answers.
> 1) What happens if two different parties want the .DIM extension?

You can only register mime-types, not file name extensions. Extensions
can be used for guessing the mime-types, but there is no strict 1:1
matching. A file extension could match multiple mime-types (in that
case you have to rely on magic value in the file to determine the
mime-type automatically).

> 2) Will this impact the mime-type?


> 3) How are 'magic, mime-type and extension' algorithms and
>     databases impacted in Linux, Unix, Windows, Apple, other
>     operating systems and web servers?

Not sure whether I've got that question right ... you can only register
mime-type names and describe the matching extensions and magic values.
It's then up to the OS maintainers to pick this information up and use
it (or in case of Hatari and Linux, we can also ship an xml file that
gets installed into /usr/share/mime/packages)

> 4) How is the mime-type determined if there is no Magic, and
>     the file.extension is ambiguously used by several parties?

That's certainly quite difficult or impossible to do it automatically.

> I expect the "mime-type Registrar" would have strict rules to
> avoid indeterminable mime-types (with ad-hoc extensions).

Actually there are currently three trees (see
The standard tree is certainly somewhat more restrictive, but the
vendor and private tree is really more or less just about registering
the mime-types itself.

> If the "mime-type Registrar" is not disorganized, I would expect
> that a .ST file would have to be put in a 'disk dump' category
> because it has no 'magic' header. Maybe this would require
> a different file.extension.

Yes, technically, a .ST file is a raw disk image file, so I am also
unsure whether it makes sense to register an official mime-type for
this. And actually, there is already a mime-type for raw disk images,
called application/x-raw-disk-image ... but I also don't think that we
want to associate Hatari with all raw disk images. So for using the .ST
images on Linux, I think we might want to stay with the "inofficial"
application/x-st-disk-image type that I already added to the repository.


Mail converted by MHonArc 2.6.19+