The Pitfalls and Perks of Adopting a New Standard 87
Monta writes to tell us that IBM DeveloperWorks has an interesting article about the pros and cons of 'adopting a standard before it becomes one'. From the article: "Whether a standard will succeed and be widely adopted is ambiguous at first, regardless of who endorses it -- a major player or a fringe element. So if most people don't like to welcome the new guy, why would they put all their eggs in a standards basket when that basket might not exist tomorrow?"
Sometimes... (Score:5, Insightful)
Chicken, meet egg.
Of course it's a gamble...
but that's one way to make the big money.
Re:Sometimes... (Score:3, Insightful)
It is, arguably, the only way to advance it. No matter how efficient a standard is at its job, it doesn't become "Standard" until successful implementation.
Good Quote! (Score:4, Insightful)
RS-232 (Score:4, Insightful)
Adoption that makes things become standard. Not the other way around. At most, all you do is create a "recommended standard", which is interestingly what the RS stood for in that famous 25-pin bus.
Re:Examples (Score:3, Insightful)
Re:Yeah... (Score:3, Insightful)
It goes like this :
So you won't get rich, but you'll get famous !
Well, not exactly famous, but lots of people will have heard of you. And they'll hate you. So it's a bit like being rich. Just without the money.
Music ID tags (Yea, OT, an On-T reply to parent) (Score:2, Insightful)
A song can have many authors.
An author can have many names
An author can have many songs
A name can have many authors
You need a many-many for song/artist, for artist/name, for name/artist ("Monkeys", for example, may not mean the same people today as it used to), etc.
In fact, you'll have many/many tables EVERYWHERE in a really complete system, and you're going to want some way to transfer information from one DB to another DB maintaining the same many/many intermediate information as you transfer across DB's
> Secondly, it's a waste to have an extra entry just for that one song.
You will wind up having to use a lot of UUID's in pairs for each table entry, and you'll have a lot of those entries. Last time I checked, generating a UUID took 16 bytes, so each line of each many/many table is a 32 byte entry, and each song will trigger many many/many entries.
Were you trying to save space somehow?