One of the things we’ve always found to be a pain is getting embeds, such as videos, bookmarks, etc, in 3rd party websites to work neatly. One of the biggest websites of course, is MySpace, who consulted with Adobe to get specific embed tag functionality added to flash 9, and promptly implemented it (linking out of a flash application, for example, is restricted) — and there really hasn’t been a good solution for this. I still don’t think there is — even though some press folks seem to think oEmbed is. It’s not, but that doesn’t mean it’s not very interesting, and worth taking a look at it. Effectively, oEmbed’s goal is to make embedding both media and metadata as simple for a consumer (or service) as knowing/having the URL to specific media. This could be achieved through a few ways, both parsing existing embed codes, or using some kind of microformat (i.e. <a href=”http://site.com/video/video-title” rel=”ombed”>Video</a>) — this is great from the perspective that I, as the application guy, can parse and get both the content/media as well as metadata about it (although, now that I’ve re-read the spec, I think there should be some more optional things in there… views, arbitrary thumbnails, original file[s] etc.. mRSS has a pretty close approximation of data that could go in this), and from the perspective of an end-user, if they’re on a page, they can post everything about that page/media/node with simply that URL.

We’re going to be implementing it in the newest version of Twiddeo — and, I hope, looking into getting an AIR-capable class implemented for it. It’s very interesting from a technical/proof of concept perspective. I think, though, the issue is two-fold:

1) There are no services, aside from Pownce, using it.

Obviously, this makes adoption tough. With only one service supporting the standard, I don’t want to pour a ton of time and resources behind implementing, standardizing and helping enhance it.

2) Users are used to simply cutting and pasting big globs of HTML. Parsing all of that fun-ness, to then try to poke for an oEmbed, would suck.

Is this the expected behavior? Parse all user input for embed, image or hrefs, then try to match all of those against some provider list, and then try to get a ping? Ugh. No? Really, part of the spec, imho, needs to be a microformat to allow this stuff to get parsed more efficiently. Right now I see a use inside of AIR (or equivilant) clients, or sites that implicitly tell people to input URLs, but for mass adoption the parsing needs to get easier.

All of that being said, I find the proposed spec personally interesting, and we’ll put some 20% time behind what makes it tick and what can make it better.

Brad

Bookmark and Share

Close this WindowBookmark and Share This Page

Save to Browser Favorites

Ask backflip blinklist BlogBookmark Bloglines BlogMarks Blogsvine BUMPzee! CiteULike co.mments Connotea del.icio.us

DotNetKicks Digg diigo dropjack.com dzone Facebook Fark Faves Feed Me Links Friendsite folkd.com Furl

Google Hugg Jeqq Kaboodle kirtsy linkaGoGo LinksMarker Ma.gnolia Mister Wong Mixx MySpace MyWeb

Netvouz Newsvine PlugIM popcurrent Propeller Reddit Rojo Segnalo Shoutwire Simpy Slashdot Sphere

Sphinn Spurl.net Squidoo StumbleUpon Technorati ThisNext Webride Windows Live Yahoo!

Email This to a Friend

Copy HTML: 

If you like this then please subscribe to the RSS Feed.

Powered by Bookmarkify™

More »