brendanheywood
commented
13 years ago I think the discussion about embed.ly the service is separate from the embedding discussion:
1) Embedding - I think this should be turned on or off depending on the medium. This means we have to do the embeding logic at display time rather than input time, or perhaps some mixed cached strategy if it's a hog. At any time a raw embedded link will still work, embedding the video etc is just a convenience. So with that in mind I'm thinking that we don't embed in print view, but do embed in web view. Embedding in comments probably shouldn't happen in the condensed crag guide view but could happen in the stream at the bottom of the page. Because this is just a value add enhancement I'm happy to leave this for a few months and let the idea settle a bit. If we called the embed service at input time we may miss out on future embed services or on better version of the embed service. If we display at run time we get a performance hit, but this can be partly mitigated by doing it fully client side in browser. I would only want to embed content in places which are already using markdown.
2) Embed.ly - this service is just a convenience, we could very easily target a small core of services we want to target and roll our own if we're worried about costs or business continuity. Eg youtube, vimeo, flickr, etc. It would be very simple, just a bunch of regex's to match each url from each service and a call to their respective oembed service. I'd be happy to rule out embedding content from a service that didn't provide an oembed service api, so it's easier for use to manage the feature and scale to new content providers. My gut feeling is that embed.ly isn't going anywhere and also for our needs we'll only need the free api anyway.
flick => http://www.flickr.com/services/oembed?url=$1 youtube => http://www.youtube.com/oembed?url=$1
See more here: http://www.oembed.com/#section7
The beautiful thing is that embed.ly is just a proxy and uses the same api so we could easily swap it in and out with the raw services. if we want to (eg if embedly dies)
As an inverse discussion the oembed spec is pretty cool, I've only recently dug into it an got up to speed. I've long wanted to be able to embed thecrag.com data in other sites and this is an ideal way to implement it cleanly.
On the topic of which content fields to embed in, this logic could be fairly difficult depending on the content. Eg embedding a flickr url of a topo made previously would be a good thing to embed into the print view, or a map made in google maps. But embedding a video in print view isn't useful. I don't think this is something we can attempt to solve and should wait and see wether people use it much before we invest much energy in it.
scd
cgome
This issue is following up Brendan's reference to
http://embed.ly/
It seems like a pretty good service. It's got a paid version and a free version.
The general idea of how it might work on our site is when somebody is writing their ascent comment they could cut and paste their flicker image url into the comments section and the image would be embedded on our pages when the comment comes up.
Before we go implement it I want to make sure this is really something we want for:
Area descriptions are intended for Crag Guide's, printed guides and iphone apps as well as the web interface. Adding a dependence to third party content may not be suitable for us in the long run.
Similarly ascent comments will be appearing in all those channels, although because of the fleeting nature of the comments the dependence on third party content will not be so crucial. Maybe we could just sanitise it for different channels and popups.
In other discussions about ascent comments, we want to attract a twitter style comment. Does embedding move away from this philosophy.
I'm also nervous about having to take away a service we offer if embedly decide to stop their free service. Until we have real revenues we are just not going to be able to lock ourselves into any paid service. If this is the only blocker then I'm happy to write to them to see what their intentions are?
My feeling is that this is not an appropriate service for area descriptions but may fit into ascent comments, but I'm not 100% convinced.
Maybe we could use embedding for a longer blog style article posted in conjuction with an ascent?