This blog post is for techies.
It’s natural for Yahoo! Media Player to support hAudio. hAudio has valuable functionality and is generally well thought out.
But it’s too big a project. The syntax is very complex. Writing a parser and accurately supporting the features is a large job which is out of scope for the media player team. The verbosity of the syntax will turn off many users. And using the syntax is too complex to do by hand; users absolutely can’t write hAudio without a dedicated hAudio editor.
What my team needs is an open source library for parsing the syntax and managing the feature set. This library would have to be small — we have strict limits on code size that are already hard to manage. The library would have to be fast — we already have a long lag time to parse big pages, and our metadata syntax can be parsed much more quickly than hAudio. The library would have to be under a license that we could incorporate into a commercial project; this probably means a BSD license.
What users need is a user interface for authoring hAudio integrated into their working enviroment. For example, editors within Drupal, WordPress, Moveable Type, and social networking sites.
I appreciate the good work of the hAudio creators. They took on a difficult and practical goal and had both the persistence and skill to pull it off. So I’m sorry to say that their project is not yet at the point where my team can take advantage of it.
The great thing about projects like this is that once the idea is moved from “there oughta be” to “this is a way to do it”, then it often looks to me as if the development community can then aim at a target and either develop solutions within the new platform or create an alternative platform. It’s a bit like the way that science fiction novels ultimately inspired space aeronautic design, except it’s more like designing a spaceship which can fly to nearest star but in the process, someone figures out a better space ship, which gets to Pluto before the prior-launched first spaceship.
Seems to me that designing the language without writing a parser is putting the cart before the horse. They would have more adoption of a worse standard that had tools.
It feels to me like a project which is still in development. A parser does make sense for a search engine, which doesn’t run in real time.
The blockers are real-time parsing while the user waits, the complexity of writing a good parser, and the complexity for users of generating the code.
The complexity of writing a parser comes from featureitus, particularly features related to hCard embedding in hAudio.
About a worse standard that had tools, I think this is a pretty likely outcome. As limited as hTrack (http://yahoomediaplayer.wikia.com/wiki/How_To_Link) is, writing a parser or hand-writing the syntax is easy.