Improved discovery mechanism

[Pelle Wessman]

While oEmbed is a good standard for getting embeddable data I've found
it to be a bit lacking at the discovery of that data.

The current discovery mechanism involves adding rel=alternate links to
embeddable resources which requires each and every resource to be
fetched and checked individually for links to know if they are
embeddable. There is currently no way to discover the URL scheme for a
host, which would be very useful since that data could be cached very
well.

I would like to suggest a new discovery mechanism based on the host-
meta specification which is part of what some call the "Hammer Stack":
http://www.flickr.com/photos/wnorris/4069639797/

I've sketched out a possible use of it in a gist: https://gist.github.com/708948

What do you think? Would this be a good way to enable discovery of URL
schemes? I would happily support it, or a variation of it, in the
oEmbed module for Drupal.

[Pelle Wessman]

Does anyone have any feedback on this? I would be happy to implement an experimental version of it, but would be nice with some feedback first.

/ Pelle

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

[Charl van Niekerk]

On Mon, Dec 6, 2010 at 12:33 PM, Pelle Wessman <pe...@kodfabrik.se> wrote:
> Does anyone have any feedback on this? I would be happy to implement an
> experimental version of it, but would be nice with some feedback first.

Sounds like a good idea, probably slightly more complicated to
implement than the current discovery mechanism but could definitely be
more efficient, especially for hosts with a lot of embeddable content.

How often does the XRD need to be re-checked though, in case the URI
scheme changes?

[Will Norris]

XRD documents have their own expiration date for caching, so it would be up to the publisher to decide.

[John Bachir]

Perhaps the reason such a solution hasn't emerged yet is because the
fundamental problem is the same: when should an oembed consumer decide
to check if a content producer has an oembed service? In the OpenID
case, the consumer knows exactly when to ask the provider -- when a
user enters a domain into the login box. For oembed, if providers have
site-wide documents specifying this, it doesn't help consumers know
when to check. In both cases, they have to check the domain of
literally every single url that they encounter.

One thing such a mechanism would improve, however, is the resources
required for the discovery process. Instead of having to download the
entire document (entire multi-megabyte flickr photo?) just to check
the headers, a consumer would just need to get the spec document
(Pelle's example is 0.5k).

Something that oembed discover would have to achieve that openid (to
my knowledge) does not, is defining the domain of documents that the
endpoint applies to. Perhaps a content provider has serveral services
and/or types of content, each with their own oembed endpoint. Pelle's
proposal seems to address this with his "scheme" properties of the
form "http://www.example.com/content/*".

Folks who were involved in the original spec (or anyone): am I right
about the challenge of deciding when to discover? Does a whole-site
discovery document have any drawbacks?

[Walter McGinnis]

Hi John,

Coming from use of OpenSearch (http://www.opensearch.org/), I assumed
a site wide discovery document for OEmbed. After rereading section 4,
I see that I assumed wrong. The discovery of the OEmbed gives the URL
for the embeddable item's specific OEmbed result.

In my use case, in theory this kind of works as I am using OpenSearch
(or in some cases provider specific APIs for search) to narrow down my
results for the user to match to the user's search term before needing
to make the actual OEmbed request.

However it still adds an request to the user's selected item's detail
page to discover the OEmbed URL.

Not very efficient. I would prefer the OpenSearch style of site wide
description document telling me what the OEmbed service's base URL is.

I.e. if I make a request to any page of a given site I would like to
find in the head:

* a link to the OpenSearch description document
* a link to the OEmbed description document

After parsing those documents, I would like to in turn use them as
configuration parameters for listing that site as a media provider
that I can query against and get back OpenSearch results. After the
user selects a result, then I can request from the service the
result's OEmbed response.

Cheers,
Walter