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

[Maciej Stachowiak]

xiphmont at xiph.org (Monty) writes:

> > I don't understand. This still means the user has to pick the right
> > program to use each time, unless it's the most preferred one (nautilus
> > does let you associated many programs with one mime type, but all
> > except the first only show up on the "Open With >" menu). On the other
> > hand, having multiple mime types and associating the same program with
> > each one is an easy task that can be done once, after which all files
> > will open with the user's program of choice.
> 
> ...or the 'preferred program' is an intelligent launcher that can look
> at the file magic.  

Some of the weaknesses of this approach:

1) The intelligent launcher needs to be configured separately from the
   user's normal file type --> program mapping

2) The user can't tell what program will be used to launch a file
   without trying it. This could be fixed by making the launcher have
   a special `--print' mode where it just prints the name of the
   program it would run. But the file manager having to launch this
   external program many times just to get this information would be
   very wasteful and poor design.

3) The user doesn't get the feedback of different icons and type
   strings for files that will be handled with different
   programs. Once again you could hack this by having a
   `--print-subtype' mode or the like for the external launcher
   program, but now it seems like you've constructed three types, only
   part of the magic sniffing is done by an external executable. This
   again seems like poor design.

4) Using such a launcher program for one mime type might be feasible
   despite the difficulties, using one for many different file types
   makes the problems above compound quite a bit.

5) It's an unnecessary (though admittedly very small) performance hit.

If you're going to present the file format as three different file
types to the user, and at a lower level dispatch to launching three
different programs, what is the value of having an intermediate layer
that pretends there is only one file type? It only seems to add
gratuitous complexity.

Why not keep it simple and have three mime types (which people who so
choose can easily map to the same icon, type string and launcher
program, or treat all three exactly the same in their application)
instead of one (where people who want three different launchers, icons
and type strings must jump through many hoops)?

> We'll be sure static magic is available and easy to use once we go
> to non-degenerate streams (and degenrate Vorbis streams already have
> static magic).

Yep, this is great, the only step that's left is mapping these magic
numbers to suitable mime types.

> Mime type is simply insufficient for identifying contents od container
> file types.  We can admit it and go on to find an adequate solution,
> or we can keep beating our heads against this already bloodied wall. I
> don't feel like saddling a technology I expect to live for a minimum
> of 20+ years with the limitations of a system we already acknowledge as
> ill-suited to the task (mime type).

mime type will definitely live for 20+ years as well, whether you like
it or not. mime type is not perfect (more than 2 levels of hierarchy
and decent support of containers are two things it does not handle
well) but it's too ingrained in too many things to go away. Life sucks
that way. 

Further, the definition of the mime types is external to the code or
file format itself. If the world ever abandons mime types, it will be
easy to ignore the previous mime type definitions.

> > Why are you trying to make things hard on people who don't share your
> > preference?
> 
> This requires only a little extra technical tinkering to make it clean
> *and* convenient.  We're no more likely to give up our design than you
> are yours.  Neither one of us has to.

I disagree. A lot of people have some prima donna file format that
they think should be handled specially, but hardcoding special
handling of each of them is a waste of valuable time. 

It's not like having three mime types ("audio/x-ogg", "video/x-ogg",
"application/x-ogg") creates a huge administrative or coding burden.

It's not like it even fundamentally affects the design, since the
magic to do the detection will aready be there.

And it has trivial effect on the user/developer experience for people
who want to treat all three types exactly the same.

I do not buy the cleanliness argument. Epicycles sure seemed more
clean than a helicentric model for a while. But the proof is in the
resulting total system complexity.

Sorry if I sound a bit strident here. I am a bit frustrated at having
to argue the same point repeatedly.

 - Maciej

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