CellarLinkerMediaMiscMoviesRamblingsRantsTechtalk

Makeover

More Sounds
If you are thinking "What's this?", see Whose Sounds in the Cellar.
If you are wondering "How did I get here?", use the back button of your browser.
If you are asking "What Sounds?", read on.

Announcing oohEmbed!

In my last post here, I mentioned some items on my ever growing TODO list and on top of that list was: Finish the web app that I've started working on.

Well, it's time to scratch that one off the list since oohEmbed.com is now live!

A bit of background before I get to what is oohEmbed. As you know, I've been working on and off on Dumble for the past several months. Now Dumble is a purely browser based application with antrix.net serving up just a bunch of static files. Because of this non-involvement of server-side programming and the web browser's same origin policy restrictions, there's a limit to how much smart URL-content-inferring can be achieved in Dumble. With the current design, Dumble can go only as far as the number of websites out there that support JSON APIs.

So on one side, I was toying around with adding a server-side component to Dumble's design to alleviate this problem. On the other, I was looking to kick the tires around Google App Engine. In between the two, the oEmbed specification was announced and thus was born oohEmbed.

So what exactly is oohEmbed? In the simplest terms, oohEmbed acts like a oEmbed API compatible proxy service between you (the developer) and target websites. For more details, visit the oohEmbed.com web site where I've described it a bit more with some examples.

Of course, I've re-written parts of Dumble to use this new oohEmbed service. You can find the forked version at oohembed.com/dumble/. If things go well, I'll designate this as the authoritative version and switch/redirect the version at antrix.net/dumble/ to it.

Thanks to the folks behind oEmbed for drafting the spec and to Google for creating App Engine. Although the App Engine environment is restrictive development wise, there's something to be said for a stack which allows one command - appcfg.py update myapp/ - deployments to the cloud! And it's all Python so I couldn't be any happier!

Please test out oohEmbed and let me know what you think. If you really want to please me, go build something on top of it!

techtalk | 2 comments | permalink | 01.06.2008 22:19 SGT


Re: Announcing oohEmbed!
Bala wrote on Mon, 02 Jun 2008 03:54

So, you are running a python app on google apps (probably using url fetch) to get the JSON data from oEmbed.com, parsing it and doing some other stuff to it, finally returning it to the caller. Now, the caller can use the JSON response to do something downstream. Question, in your google apps implementation, are you parsing the JSON responses in Python? For dumble implementation on oohEmbed.com, you either get the url content inferring for free because of oEmbed.com or you have to do it, correct?

Sounds cool, but I can't think of an application (for me) to use it.


Reply to this comment
    Re: Re: Announcing oohEmbed!
    deepak wrote on Mon, 02 Jun 2008 12:52

    oEmbed.com actually just hosts the spec, it isn't involved anywhere in the actual implementation.

    Given a request url from a caller/consumer, the oohembed service can return a URL response in one of three ways:

    1) The url points to a site which already has an oEmbed spec compliant provider. e.g. Flickr, Pownce and others listed at oembed.com. In this case, oohEmbed just fetches the response from the correct provider (as per the request url) and returns the response as-is to the consumer.

    2) The url points to one of the video sites like Youtube which have generic embed codes that can be generated on-the-fly using a template and some kind of unique identifier from the URL. In this case, there's no urlfetch on the oohembed side. It just creates an appropriate json response and sends it back to the consumer.

    3) All other sites. In this case (like Amazon, Wikipedia, Twitter, etc), oohEmbed has to fetch either the raw html page that the request URL points to, or query the respective site APIs to get a response. Then modify the response in the format that the oEmbed spec stipulates and send it back to the consumer.

    The json->python->json wrangling is handled by the simplejson module.

    And yes, now Dumble only has to implement rendering logic for the 'photo/video/link' response types as defined in the oEmbed spec. For every link, Dumble queries oohEmbed. If it gets a valid JSON response, it looks at the type of response and formats the HTML appropriately - agnostic of the actual site the URL points to.


    Reply to this comment

 
Name:
URL:
Title:
Comment:
Please type spam captcha image in this box

SnapShot

Most things here are Copyright © Deepak Sarda. Design courtesy of Bruce Alderson [warpedvisions.org]