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

[David Savinkoff <dsavnkff@xxxxxxxxx>]

Hi Thomas and Eero,

Thank you for the information (I read the links you provided also).

Sincerely,
David Savinkoff


----- Thomas Huth wrote:
> Am Sat, 6 Dec 2014 11:08:59 -0700 (MST)
> schrieb David Savinkoff
> 
> > ----- 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/vnd.fast-copy-disk-image
> > > - application/vnd.fast-copy-dim
> > > 
> > > 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?
> 
> No.
> 
> > 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
> http://en.wikipedia.org/wiki/Internet_media_type#Registration_trees).
> 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.
> 
>  Thomas
> 
>