Some concerns about oEmbed, and an early alternative proposal

[bmearns]

(I hope nobody takes this personally). I've written up a document that describes some concerns I have with oEmbed, as well as some proposals for how the oEmbed features can be implemented a different way using standard HTML5 features. I'm not promoting this alternative, at least not until I hear some feedback from oEmbed community. I'd like to gain the benefit of your experience in this area: feel free to point out why my concerns are invalid or valid but worth while. Any constructive feedback is welcome: if you convince me that oEmbed is superior, all the better since it's already widely adopted.

https://sites.google.com/site/embedlink/home

Thanks!
-Brian

[Ross Boucher]

As a starting point, it's probably worth pointing out that oEmbed could easily be considered dead. Though there are some large implementations, new ones aren't really appearing, and there's not really any discussion here or elsewhere about the spec. 

Facebook's open graph protocol (http://ogp.me/) basically accomplishes what you're proposing in a similar way, and it's widely implemented on real world websites. They have a discussion group, but I could not speak to how open they are to changing the protocol. I'd recommend checking it out and sending them an email.

From a practical perspective, the one thing that's somewhat unfortunate about open graph and to your proposal is that working with HTML can be fairly obnoxious (and delivers a ton of content you don't want). That being said, not having a separate API endpoint is a pretty big plus, and if servers support HEAD requests appropriately you can mitigate some of the overhead.

--
You received this message because you are subscribed to the Google Groups "OEmbed" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oembed+un...@googlegroups.com.
To post to this group, send email to oem...@googlegroups.com.
Visit this group at http://groups.google.com/group/oembed?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ryan Baxter]

Something else to keep in mind that is similar to oEmbed is embedded experiences, which is part of the OpenSocial spec [1].  It has some nice advantages over oEmbed in my opinion.

[1] http://opensocial-resources.googlecode.com/svn/spec/2.5/Core-Gadget.xml#Embedded-Experiences

[bmearns]

On Tuesday, February 26, 2013 9:51:44 PM UTC-5, Ross wrote:

As a starting point, it's probably worth pointing out that oEmbed could easily be considered dead. Though there are some large implementations, new ones aren't really appearing, and there's not really any discussion here or elsewhere about the spec. 

Facebook's open graph protocol (http://ogp.me/) basically accomplishes what you're proposing in a similar way, and it's widely implemented on real world websites. They have a discussion group, but I could not speak to how open they are to changing the protocol. I'd recommend checking it out and sending them an email.

From a practical perspective, the one thing that's somewhat unfortunate about open graph and to your proposal is that working with HTML can be fairly obnoxious (and delivers a ton of content you don't want). That being said, not having a separate API endpoint is a pretty big plus, and if servers support HEAD requests appropriately you can mitigate some of the overhead.

Aha, well that's certainly good to know =). I've looked at open graph and you're right, my proposal is very similar. My initial impression is that OG is a suitable standard that makes my proposal likewise obsolete. (Although I find it a little unfortunate that they used meta tags for so many things that link tags probably would have been more appropriate for).

I'm not sure I understand your comment about working with HTML. Is it that oEmbed allows you to bypass parsing the HTML once the endpoints are known and query just oEmbed data itself?

[Sergey Chernyshev]

Guys, you might want to look into RDFa in general, not just OpenGraph, it definitely does what you're looking for.

HTML parsing compared to discovery is not necessarily bad, simplicity of "get the page in question, since you have it, just parse data put of it" is winning with most developers who have hard time following complicated HTTP manipulation sequences ;)

--

You received this message because you are subscribed to the Google Groups "OEmbed" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oembed+un...@googlegroups.com.
To post to this group, send email to oem...@googlegroups.com.
Visit this group at http://groups.google.com/group/oembed?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Thank you,

         Sergey


--
Sergey Chernyshev
http://www.sergeychernyshev.com/

http://www.meetup.com/Web-Performance-NY/

http://www.showslow.com/

[Sean Creeley]

Dead is a pretty FUDy description for what's actually going on here.

Almost every major social platform uses oEmbed in some fashion.
Twitter, Pinterest, LinkedIn, SoundCloud all consume oEmbed data.
Flickr, Twitter, Instagram, YouTube, Vimeo and hundreds more offer an
oEmbed endpoints. It's built in to the core of many products like
Wordpress.

So Dead is the wrong term. The spec however has definitely been
neglected and it probably needs an update for the modern times. There
isn't even an "Audio" type embed, so that should probably be
addressed.

The beauty in oEmbed is it's simplicity, it's a great starter API and
is widely adopted because of that. If there is another pass at the
spec, then I hope it remains simple.

There are a ton of specs out there that one could point to as an
alternative. I'm sure a Google guy will jump in and says how awesome
Open Schema is. The point here is that you aren't going to make a
client side javascript call to embed a video using Open Graph, Open
Schema or RDFa

For purely embedding, not scrapping sites, oEmbed is still the best
spec out there.

If you want a wish list of what needs to change, I'll start:

* Audio type
* callback declaration
* https endpoint declaration
* A standard licensing declaration
* Wording that states strongly that all video, rich, audio embeds
SHOULD be served by the provider in an iframe.
* CORS support

Sean

On Tue, Feb 26, 2013 at 9:51 PM, Ross Boucher <rbou...@gmail.com> wrote:

--
Sean Creeley | Co-Founder Embedly
205 Portland St #201 | Boston 02114
415.891.9917 | se...@embed.ly | @screeley
http://embed.ly | @embedly

[John Pettitt]

A lot of the objections in the doc Brian wrote could be solved if there were a standard for communicating with iframes.

Specifically if an endpoint could return and iframe url and there were a standard javascript library for the frame to communicate with the parent using postMessage almost all of the security sandboxing issues would go away. The frame would need to be able to request a resize, request font and color info etc. If such a standard existed you could request an article, throw it in an iframe and know that it would negotiate with the parent frame how it wanted to be displayed.

If anybody else likes this idea ping me - I'm up for helping create it and publishing the code ....

John

[Ivan Paramonau]

Thanks all for bringing it up. 

The challenge is not to come up with a new spec, but to make the change happen and it means to onboard a lot of providers, publishers and consumers. Pretty much, classical chicken-and-egg.

My team (Iframely) stumbled upon similar limitations of oEmbed a year ago. And we have being digging through various challenges since then. Like unifying discrepancies between the providers, analyzing alternative approaches and various consumers' needs as well as outlining and testing the spec which stands the chance to be adapted.  

The spec's working title is oembedgraph, as it builds upon oEmbed, Open Graph (RDFa), FB Graph API concepts and HTML5. Oembed was a breakthrough step, but it certainly is not an ultimate answer either for semantics nor embeds rendering. 

Here's our internal debug tool for those who want a sneak peak:

* Video: http://iframe.ly/pageinfo?url=http%3A%2F%2Fvimeo.com%2F53156464 

* Photo: http://iframe.ly/pageinfo?url=http%3A%2F%2Finstagram.com%2Fp%2FR15nF%2F 

* Article: http://iframe.ly/pageinfo?url=http%3A%2F%2Fmashable.com%2F2012%2F11%2F02%2Fcuriosity-rover-self-portrait%2F 

* Audio: http://iframe.ly/pageinfo?url=https%3A%2F%2Fsoundcloud.com%2Fchoicecuts%2Fdj-krush-live-at-choicecuts 

The discovery mechanism isn't perfect there yet and we're changing it at the moment. To get an embed you just go to iframe.ly/{ID}. We also need to understand how we write the connectors for ssl requirements.

Even though it's a little earlier than we anticipated to come out of stealth, the conversation seems right and calling for it. 

* We do not have a written spec yet, but the API/protocol endpoint is available in alpha (well, it's under it's 4rth refactoring at the moment too).

* The API has sufficient provider coverage and is a connector that converts a lot of existing oEmbed and not-so-oEmbed providers to meet the spec. We hope to be removing connectors as providers start to adapt to the spec.

* It's in alpha, meaning we need some more developers to try to build upon it to see if it's really what it should be. We built two apps ourselves in order to create the API – http://nowork.fm and http://iframe.ly, so we are ready to start opening it up now.

* Our plan is to publish an endpoint as free service in the next couple months (well, perhaps some setup fee to keep our servers running). Or even open-sourcing it too, as providers/connectors change so fast it is becoming a challenge for us to keep up ourselves.

* We will be happy to keep changing the endpoint to incorporate requests for the community. However, we need to make sure that foundation is right first.

So, and sorry for solicitation, if you'd like to participate in early alpha, please, cast your email here: http://iframely.com 

People who can make the change happen within significant providing or consuming players – please,   reach me directly at i.paramonau at gmail. We'd need some serious support behind the updated/new specs when (or even better - before) it's published.

We will certainly make further announcements here as well once we confirm the substance.

 

[bmearns]

On Wednesday, February 27, 2013 11:35:49 AM UTC-5, John wrote:

A lot of the objections in the doc Brian wrote could be solved if there were a standard for communicating with iframes.

Specifically if an endpoint could return and iframe url and there were a standard javascript library for the frame to communicate with the parent using postMessage almost all of the security sandboxing issues would go away.   The frame would need to be able to request a resize, request font and color info etc.   If such a standard existed you could request an article, throw it in an iframe and know that it would negotiate with the parent frame how it wanted to be displayed.

I'm not really clear on why the iframe needs to communicate with the parent doc. Are you suggesting that the iframe itself would provide the appropriate meta data like media dimension and mime-type? Seems like a significant complication: I'd rather use the original oEmbed mechanisms and just replace the html property with a URL pointing to an iframe. Or, as I've described, use some more conventional HTML mechanisms for relaying the meta data.

[John Pettitt]

The problem with the html response you really can't predict that it will fit it the box provided without knowing a lot more about the users browser and the target page.   You need to know fonts, font size, line spacing and be able to predict how the browser will render the content - otherwise you almost always end up with scroll bars on an iframe which sucks from a UI standpoint.

Fixed sizes work for fixed size content like video players and images, for text you need flexibility.  In most cases it's more useful for the iframe to be able to say "I need to be this many pixels long to render this content" and have the parent resize it.  we do this on Repost.Us, disqus does it for their comment embeds, storify does it for their embeds.    In all cases the embedding site has to trust our javascript is going to correctly create a frame and sandbox it's content.   If there were a standard way for frames to communicate there would be no need to trust foreign scripts.

John

[bmearns]

On Wednesday, February 27, 2013 8:56:32 AM UTC-5, Sean Creeley wrote:

[snip]

The beauty in oEmbed is it's simplicity, it's a great starter API and
is widely adopted because of that. If there is another pass at the
spec, then I hope it remains simple.

I disagree on this point: conceptually, yes, it's simple. But implementation wise I think it adds unnecessary complication for both the provider and the consumer. On the provider side, they have to do dynamic content generation and query string processing; as far as I can tell it's impossible to implement oEmbed with static resources. On the consumer side, it seems that the only safe way to consume video and rich types is to serve an iframe from a separate host name, which is a fair amount of complication (and expense) in some cases, and may not even be possible in others. And as far I I know, the fact that the data is served as a resource distinct from one it describes also means that consumers cannot be implemented in Javascript, for instance, since they can't fetch a resource across domains.  

 

If you want a wish list of what needs to change, I'll start:

  * Audio type
  * callback declaration
  * https endpoint declaration
  * A standard licensing declaration
  * Wording that states strongly that all video, rich, audio embeds
SHOULD be served by the provider in an iframe.
  * CORS support

I don't think strongly suggesting that content is served in an iframe is enough: I think the whole idea of sending back raw HTML is the worst part of the entire spec. Sure, we all know not to drop this HTML directly on our page, but not everyone does, and not everyone is going to read the spec. I, for instance, only learned about oEmbed because I saw it being used by youtube, so I just looked at the data and started using is. I didn't read the spec until much later, and that was only because I was looking for some additional features. Fortunately, I already knew to use an iframe but again, not everyone will, and we can't assume that any warning, no matter how strongly worded, is going to be seen.

If the provider wants to serve rich HTML content, the response can include a URL that the consumer can point an iframe at. At least then the simplest and most obvious way to handle it is fairly safe. though frankly, I still thing providing HTML directly or indirectly has limited good use cases, and just pointing at the actual media file (as with the Photo type) is preferable.

-Brian

[bmearns]

On Wednesday, February 27, 2013 12:48:50 PM UTC-5, Ivan Paramonau wrote:

You can not build one without the other. If you need to introduce new spec you need to start it's adaption. We chose to start it by giving consumers a good coverage of providers under new format. 

It doesn't matter for our business which format it'll be, we just need one that is widely adapted. The one that we are ready to start providing answers a lot of your concerns as well as some others. We still need some tweaks and some community alpha feedback until the spec can be published though.

Okay, so you are working to define a new format for providing the data, and the service is a demonstration of this new format which also aggregates existing formats from other sites and provides it in the new format, is that correct?

 I couldn't really glean much about how it works from the example services, but I'd be very interested to see the general concept. I guess it works similar to oEmbed in that it queries a separate resource that provides the data for a page? It appears you're using iframe URLs, instead of directly responding with HTML, which I'm glad to see.

-Brian

[bmearns]

On Wednesday, February 27, 2013 12:53:48 PM UTC-5, John wrote:

The problem with the html response you really can't predict that it will fit it the box provided without knowing a lot more about the users browser and the target page.   You need to know fonts, font size, line spacing and be able to predict how the browser will render the content - otherwise you almost always end up with scroll bars on an iframe which sucks from a UI standpoint.

Fixed sizes work for fixed size content like video players and images, for text you need flexibility.  In most cases it's more useful for the iframe to be able to say "I need to be this many pixels long to render this content" and have the parent resize it.  we do this on Repost.Us, disqus does it for their comment embeds, storify does it for their embeds.    In all cases the embedding site has to trust our javascript is going to correctly create a frame and sandbox it's content.   If there were a standard way for frames to communicate there would be no need to trust foreign scripts.

John 

Ok, I see your point, and I agree about scrollbars in iframes. The parent document can't poke into a cross-domain iframe? I thought it was just that the iframe can't look up.

-Brian

[John Pettitt]

On Feb 27, 2013, at 10:10 AM, bmearns <mear...@gmail.com> wrote:

Ok, I see your point, and I agree about scrollbars in iframes. The parent document can't poke into a cross-domain iframe? I thought it was just that the iframe can't look up.

-Brian

You can't see into an child xdomain  iframe - otherwise it would be trivial to frame a bank site and snoop the contents of the password field which would be a bad thing.

There are two ways to communicate via cross domain iframes 

1) use javascript postMessage

2) if your have a stone age browser signal via the #part of the url (really)

There is a jQuery extension that handles it all pretty well  http://benalman.com/projects/jquery-postmessage-plugin/ 

John

[bmearns]

Ah, of course. I was only considering the security implications of someone getting an iframe to load on another site (say for instance a public bulletin board), and using it to snoop passwords there (which of course they can't because it's cross domain). As usual, I'm glad there are folks smarter than me working on things like this.

[Leah Culver]

FYI - you can submit pull requests to the spec here: https://github.com/iamcal/oembed

I don't see any open pull requests, so I'm assuming they will be looked at. :)

Hope that helps!

Leah

[Sergey Chernyshev]

Are there any white papers I can show my (content) business that will convince them there isa good business case for oEmbed? A year or two back the only valuable use we saw was integration with twitter, but only available for preferred partners which somewhat defeats the purpose of adopting open standard for content providers.

I'd love to resurrect the embed project with our site rebuild that is coming up and if there is an easy convincing peice of writing (with pictures ideally) that helps with building a business case, that'd be awesome!

home | embedlink

--