oEmbed isn't dead – here's OU Embed!
Despite appearances, I argue that oEmbed is alive and kicking.
Cloud created by:
23 April 2013
Brian Mearns has put together a document describing some concerns around the oEmbed standard, partly around security. It's generally very useful. The discussion on the oEmbed Google Group goes onto whether oEmbed is dead, and what the alternatives are.
I welcome the discussion, particularly the notes on alternatives. However, I'll add my voice to that of Sean Creeley, CEO of Embed.ly, and say that yes the specification has languished (though it is on Github - this should help keep it alive). But oEmbed isn't dead!
I concur that the benefits of oEmbed include:
- Wide adoption,
- The ability for site X to provide a ''proxy'' oEmbed service on behalf of site Y,… for embedding in site Z.
I also second Sean's wish list.
I should also probably apologize and pick up on Ross' point that "Though there are some large implementations, new ones aren't really appearing…". So, I'm standing up to be counted…
We've been developing an oEmbed service here at The Open University for several years. We are using it as the vehicle to ease deployment of our OU Media Player, which is accessible (to those with disabilities), easy to embed (largely because of oEmbed), and OU branded.
OU Embed is also a vehicle to:
- Embed from and for research-based projects, for example Cloudworks, CompendiumLD and iSpot;
- Quickly deploy embedding services, for example, for visualizations on Scraperwiki;
- Provide accessible alternatives;
- Experiment with HTML5, RDFa and so on.
OU Emded is written in PHP, based on CodeIgniter, and I hope to release (most of) it open-source in due course.
- The oEmbed specification
- Specification source on Github
- Discussion on oEmbed Google Groups
- Brian Mearns' document
- oohEmbed.com ''proxy'' - merged with Embed.ly in 2011
- Noembed.com proxy - very useful
- Embed.ly proxy - good service, large
- Iframely proxy - a new player, v. interesting
Having thought some more, I suggest that precisely because the oEmbed specification is simple, it is already widely deployed, it works "under the hood", and people can do what they want with it (it just works), there is perhaps the ''perception'' by stakeholders that we don't need to refresh the specification and deal with issues.
As the Google Group discussion reveals though, we need to both nurture oEmbed and ensure that it is seen to be alive.