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

[Michael Smith]

>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?

>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? 

>
>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.

>
>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.

>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.

Michael

--- >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.