[vorbis-dev] Mime Type and Ogg (More)
dconti at acm.wwu.edu
Mon Nov 13 17:00:52 PST 2000
On 13 Nov 2000, Maciej Stachowiak wrote:
> xiphmont at xiph.org (Monty) writes:
> 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.
I dont see how you expect it to survive for 20+ years when such a
challenge exists to adapt it to container types. See more below.
> 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.
So what happens when someone puts a meta data stream for lyrics in an ogg
bitstream? Or (for whatever reason) someone streams subtitles along with a
movie, but in a seperate stream? Maybe the administrative or coding burden
is small now, but your approach generates recurring maintenance.
> 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.
My compliments to you for your ability to religiously argue your point in
the face of so many non-believers. I urge you to consider that you have
consistently used a linear and restrictive approach to how files should be
treated by any given system; not once have you considered that rather than
adapting ogg to suit your needs, that a more reasonable solution
exists. I also urge you to consider that, whereas this is a project in
development and input at this phase can possibly impact results, there are
other bitstreams that are have been through a few revisions, and if your
system can't properly address this problem with ogg then it will likely
have trouble with those formats.
And that's the sum of my interest in beating this dead horse.
> - 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.
--- >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.
More information about the Vorbis-dev