Last modified: 2014-05-01 12:26:23 UTC
The oEmbed protocol is used by a number of sites to make it easier to get thumbnail images or inline video player code for a foreign-hosted media entry that we've just got a URL for. We use this in StatusNet to fetch previews and video embedding for remote media. Spec: http://oembed.com/ oEmbed data can be read via JSON or XML formats; this may be a good candidate for a custom API module like the opensearch suggestions. Note that there's an oEmbed proxy service which provides basic metadata on articles for Wikipedia: http://oohembed.com/oohembed/?url=http%3A//en.wikipedia.org/wiki/Bridge but it does a poor job on images, where it's really more important: http://oohembed.com/oohembed/?url=http://en.wikipedia.org/wiki/File:Akashi-kaikyo_bridge3.jpg We should be able to expose most files as 'photo' or 'video' types, which lets us include a thumbnail URL, and inline HTML for Ogg video players etc. Compare with Flickr and YouTube entries: * http://www.flickr.com/services/oembed?url=http://www.flickr.com/photos/brionv/4936308232/&format=json * http://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=1tjC0mYfcrg&format=json There are also optional 'maxwidth' and 'maxheight' parameters, which can be used to specify what size thumbnail or inline image/video player you want; the resulting photo/thumb URL or HTML should match. <link rel>s can specify the JSON and/or XML discovery URLs for the item on the current page, and should be provided to third-party services will pick it up. I _think_ we should be able to make the video handling pretty general by grabbing HTML fragments from the media handler, though I'm not 100% sure.
Doing this properly in api, requires solving bug 25624 first. Until then JS screenscraping for Stockphoto and video embed script is the only option to properly provide embed services with appropriate licensing and attribution conditions.
(In reply to comment #1) > Doing this properly in api, requires solving bug 25624 first. Until then JS > screenscraping for Stockphoto and video embed script is the only option to > properly provide embed services with appropriate licensing and attribution > conditions. oEmbed doesn't expose license info directly, so the buck can be passed for now; whatever our embedded player HTML includes will go in there, whatever doesn't won't. :) (I'm not 100% sure the current state of embedded player helpers for Ogg player; if we have to rig one up, it should probably include text data or link to it, leaving the 'where's the license info' for 'go look at the link'.) I've started a stub implementation for the API point in a separate git project since it's not too convenient to do a work branch in SVN yet: http://www.gitorious.org/mediawiki-oembed http://www.gitorious.org/mediawiki-oembed/mediawiki-oembed/commit/8ddaf0cc918c32a35247472acfb3b8d5289c464c
Removing dep reference for bug 25624 (machine-readable license info exposed through API). oEmbed doesn't provide license information directly; the embedded player might wish to be able to get at it, but that's out of scope for oEmbed providers and consumers. Added dep ref for bug 25862 (stable URL interface for media embedding).
OK, lets just put it this way then. The Commons community has been highly resistant to any embedding service that does not provide full attribution and license information. They will not settle for "Click here to read the license info" and would request that such a feature is disabled until such a time that such information IS provided inline with the embedding. Stockphoto has shown as much.
(In reply to comment #4) > OK, lets just put it this way then. The Commons community has been highly > resistant to any embedding service that does not provide full attribution and > license information. Last time I checked Wikimedia allowed remote linking of images, and I don't think that is going anywhere. oEmbed is scarcely less primitive, are they really opposed to it?
Some notes on the video embedding. We would probably want use an iframe html like youtube and the current mwEmbed gadget based video sharing works. The main reason for this is you need javascript support code for the embed players to work. ( ie you have to switch among available video sources and playback methods ) and embedding an iframe is a lot safer then remote javascript. i.e Compromised 3rd party hosted medaWiki installs won't be able to run arbitrary javascript on any page the player is embed on.
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
See also bug 19043 which notes issues with OggHandler + ForeignAPIRepo/InstantCommons: the Cortado java video player sitting on the local domain is unable to download and play offsite Ogg videos. Using the same embedding iframe stuff for things exported over ForeignAPIRepo might do the job nicely.
Adding a note that facebook now supports open graph html5 sources: http://developers.facebook.com/docs/opengraph/ So we could now in theory embed html5 wikimedia video inline in facebook with our player and full commons author attribution. oEmbed and open graph support would be nice easy win features for Timed Media Handler. But we have new feature lock down until we first get ~a version / release~ of TMH out there.
(In reply to comment #2) > I've started a stub implementation for the API point in a separate git project > since it's not too convenient to do a work branch in SVN yet: > > http://www.gitorious.org/mediawiki-oembed I was thinking of an API to embed wiki articles/infobox to external sites. Maybe it can be done using oembed but I am not sure if I can do it as I am new to Mediawiki.Let me know if I can help.
Note that there's a proposed successor protocol to oembed: http://iframely.com/oembed2
Hi, this project is still listed at https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Extension:OEmbedProvider Should this project be still listed in that page? If not, please remove it. If it still makes sense, then it could be moved to the "Featured projects" section if it has community support and mentors.
