[vorbis-dev] Mime Type and Ogg (More)

[Ali Abdin]

* Michael Smith (msmith at labyrinth.net.au) wrote at 17:23 on 14/11/00:
> 
> >There is no "standard" for determining a file's type except through 
> >mime-type (and extension (according to windows)). If Eazel/Nautilus 
> 
> No. Wrong. This is one of your main misconceptions that is making this
> whole argument even less productive. MIME type is completely and absolutely
> unrelated to determining a file's type. MIME types are used for associating
> a name (a string) with a specific filetype. 
> 
> The process of determining what that file type is is entirely orthogonal to
> the actual naming of that type. For instance, consider a mac-based
> webserver. The filesystem gives you the filetype. The webserver would then
> convert that type-name (a short creator code, as I remember) into a
> different type-name - the MIME type.
> 
> It may seem like this is a fairly minor point - but it isn't. It's a
> fundamental distinction essential to making this whole thing make sense.
> Basically, there are 3 seperate problems:
>   1) Determining filetype.
>   2) Mapping that filetype to a unique identifier, such as a MIME-type.
>   3) Mapping named filetypes to actions.
> 
> 3 is pretty much irrelevent to this discussion - it's pretty hard to do
> well, but doesn't particularly depend on the method used to name your
> filetypes, and is completely unrelated to the actual contents and/or name
> of the file. I imagine you guys have this particular one well under
> control, app-side.
> 
> 1 is fairly difficult in general. After some thinking about this, my
> opinion is that the only sensible option (assuming a lack of filesystem
> level metadata) is a combination of filename searching (usually looking at
> the extension), and some form of 'magic number' check. You need the
> extension check mostly for files which are not uniquely identified as a
> particular type by inspection of the contents (a lot of text-based stuff
> falls in here). 
> 
> Now, what you want here is some sort of magic number in file formats to
> allow easy identification. A good idea. But what are you trying to
> identify? In the case of ogg/vorbis, the filetype is ogg. The contents of
> that file may then happen to be vorbis, but the file itself is ogg, beyond
> any doubt. Hence the only logical mime-type to give this is
> application/x-ogg. Unfortunately, this isn't particularly useful in
> practice, for what you're using MIME-type for. The problem? MIME types are
> insufficient to describe the situation. That sucks, but it's a fact. 
> 
> Now, it's still useful to be able to not only identify a file's type, but
> also to identify what the contents of that file are (because, really,
> knowing what type of file you have isn't useful. You want to know what it
> contains.) So, we're willing to help here (for now, since all ogg streams
> are degenerate, there's sufficient information anyway. Later, once complex
> stream types exist, further useful information will be provided.) That's
> not really solving the problem though - the problem is that MIME types are
> unable to do what you want them to. No matter what contortions you go
> through, they'll remain inadequate. Sucks, doesn't it?

The semantic of what mime-type actually is not important to me. It wasn't part
of my argument.

I was just lazy in saying that mime-type == file-type instead of saying
mime-type is a label that is associated with a specific file-type
 
> >developed its own scheme that fixes the mime-type's defficiencies, it 
> >wouldn't mean jack shit because nobody would use it (not to mention that 
> >other people will complain that Nautilus has its own "weird" non-industry 
> >standard requirements).
> 
> I _really_ don't understand this. Nautilus would use it. Anyone who uses
> Nautilus would then use it. As I understand things, Nautilus is some form
> of file manager, right? What widely used systems use MIME types? The web,
> and email. Since Nautilus is neither a web server nor a mail client, why
> does using MIME types gain you anything? You aren't interoperating directly
> with anything that DOES use MIME-types, so any scheme you use is creating
> the information from scratch (by file type sniffing). Surely whatever
> filetype-naming scheme you use is solely internal to the application? (It'd
> be nicer if it was real filesystem metadata. Unfortunately, unix doesn't
> give us a way to do that.)
> 
> There are (currently, anyway) _no widely used_ file managers which use
> mime-types for this. As a result, why would using a new scheme make
> Nautilus 'weird'? If the system is better (and given even a small amount of
> thought, it would almost HAVE to be better), then people certainly wouldn't
> _complain_.
> 
> Am I missing something here? 

Yes, its called interoperability (with KDE/Konqueror for example).

There is also the fact that Nautilus interfaces with the internet (HTTP/FTP)
which use mime-type.

Also, nobody has proposed an alternative to the mime-type system. It is unfair
to tell the Nautilus developers "Go develop a new non-broken mime-type system"
because we won't support mime-type.
 
> >
> >Now the problem is if every person creating a new file-format would use 
> >their own "scheme" of determining the file's type (because mime is 
> >insufficient) then programs like Nautilus will be hard-pressed to support 
> >all these new different schemes for determining a file type (especially 
> >since each one will have its own "unique" way of doing things).
> 
> We're suggesting no such thing. What _we_ need to do is give you a good way
> to be able to identify file type - and we've said we'll do that. What we
> _are_ suggesting is that, since MIME-types are incapable of correctly
> describing file types/contents, you should use a different scheme. You then
> have to support precisely ONE scheme - maybe two if you want to keep MIME
> types for backwards compatibility with previous versions of nautilus.

I do not understand why there is an argument anymore - You said you will give
us a way to identify a file type. This is what we wanted. Why is there this
big argument now?

There is no different scheme the EXISTS ON UNIX that we can use!!! You are
basically saying "you are writing a file manager, therefore it is your
responsibility to write a non-broken scheme to replace mime-type." - In theory
thats nice if we get a non-broken scheme, but in reality: A) this new scheme
will probably have "issues" (nothing is perfect) and B) It won't get support
from anybody (since it is a Nautilus-specific thing that nobody discussed or
even agreed upon).

> >
> >And note - this is not actually a Nautilus issue, it is a gnome-vfs issue 
> >(just in case you think this is some sort of 'corporate Eazel conspiracy')
> 
> I don't think anyone involved here thought anything of the sort. We're
> trying to help you guys solve a serious technical problem with your
> program, nothing more.

And here we were trying to help you guys solve a serious problem with your
file format ;)

> >I also thought the Ogg developers were looking into supporting the 
> >mime-magic stuff?
> 
> As I mentioned above - yes, we will add appropriate information for 'magic
> number' ogg file description metadata. Not 'mime-magic' - but information
> usable for filetype id. A useful distinction to make.
> 
> Sorry if I've come across overly agressively - I just feel that we should
> try and solve this the RIGHT way, instead of using some simple but bad
> solution.

Let me switch the burden around. Could you come up with the RIGHT way of
determining a file type and inform us when you have done so?

We both agree that mime-type is broken. You've agreed to add the filetype id
stuff. We've agreed to use it (when its done). What are we arguing about?
(from my understanding, you are telling us to go and create a new scheme to
replace mime-type?)

Regards,
Ali

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.