The past few months, I've written about the Facebook API, which allows third-party developers to integrate their applications into Facebook. A large number of such applications exist already, and more are being created and released every day.

However, Facebook isn't the only social-networking site out there. Indeed, Facebook isn't even the largest social-networking site—although it is the fastest-growing and seems to have a great deal of momentum. This is due in no small part to developers' ability to create and integrate new applications into Facebook. And, although most Facebook applications are (I think) pretty silly, that hasn't stopped people from trying them and even using them on a regular basis.

Facebook's offer of a developer API definitely was a good thing for Facebook users. But, it was bad news for at least three other groups of people. First, users of other social-networking systems suddenly were faced with the prospect of using a less-popular system. (In the world of social networking, a less-popular system also is less desirable.) Second, the people running non-Facebook social-networking sites, such as LinkedIn and MySpace, suddenly were faced with the prospect of their users leaving for Facebook. Finally, software developers began to look at Facebook as the most-desirable platform for which they should develop, because it had the largest user base. Even if one or more of the competing sites were to unveil an API, and even if it were as rich as the Facebook API, it probably wouldn't reach enough users to make the doubled effort worthwhile.

So, I was fascinated to learn, via Marc Andreessen's blog, that a number of social-networking sites were responding to Facebook in a way that satisfied all three of these populations. They announced an API that would allow an application to work across many different social-networking sites. This API, known as OpenSocial, can be added to any site (“container”) or application. If you write a Facebook application, it'll work only on Facebook. But, if you write an OpenSocial application, it'll work under Ning, MySpace, Orkut and nearly a dozen other systems.

Of course, OpenSocial isn't exactly the same as the Facebook API. And, in fact, it has some disadvantages when compared with the Facebook API. Also, as I write these words in mid-December 2007, OpenSocial still is stuck in an early beta release.

However, OpenSocial is interesting from a few perspectives. First, it's an interesting shot across Facebook's bow, and one that deserves our attention, if only because it demonstrates the lengths to which companies now will go to attract developers and users. But, it's also interesting because it's the first application standard I can think of that is based on HTTP, JavaScript and HTML. That is, I believe OpenSocial is the first Web development API that is completely client-side, rather than server-side. If nothing else, this shows how important JavaScript has become to Web developers.

This month, we start looking at OpenSocial from the perspective of an application developer. OpenSocial builds on work done at Google; thus, it's based on several technologies developed at Google, including Google Gadgets. So, let's begin our discussion of OpenSocial by looking at Google Gadgets and how we can create and use them. Next month, we'll look at how to turn a simple gadget into a social gadget and connect it with OpenSocial containers.

An OpenSocial application is, at heart, a combination of XML and JavaScript, using a special version of Google Gadgets. The code is written in JavaScript, and preferences and guidelines for the gadget are set using XML. The simplest possible gadget, taken from Google's on-line documentation, is the following:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
  <ModulePrefs title="Hello world" />
  <Content type="html">
     <![CDATA[
       Hello, world!
     ]]>

  </Content>
</Module>

The above gadget, as you can imagine, doesn't do very much. The first line shows that it's an XML document and that it's encoded using UTF-8. This means we can write gadgets in any language we like, and they should work correctly. The gadget is then contained inside <Module> tags, apparently because gadgets were called modules when they were under development. The content of a gadget sits inside a <Module>.

There are three potential sections inside a gadget:

The above test gadget doesn't contain any UserPrefs, and its Content section contains only HTML, but it still is valid.

To see this gadget in action, you need to create an iGoogle page. This requires having a Google login. (I'm familiar with the privacy concerns that are increasingly raised about Google. OpenSocial will not be tied to Google; thus, it doesn't require a Google login. However, for the time being, it's easiest to create a gadget for an iGoogle page.) Go to your personal iGoogle page: google.com/ig.

On the right side of the screen is a link called Add stuff. This is how you add new gadgets to your personal iGoogle page. By default, it shows the most popular gadgets, and you're obviously welcome to add as many or as few of these gadgets as you want. However, if you're going to be developing gadgets, add the My Gadgets gadget, which gives you some additional control and functionality. Use the search box to find My gadgets, and when you find it in the search-result listing, click on the add it now link. You will be brought back to your iGoogle page, with this new gadget now available.

Google has tried to make gadget development as easy as possible. One way it eases the learning curve has been through the creation of many on-line tools that remove the editing and storage needs for many developers. Thus, although many Web developers (like me, and possibly you) are happy to write programs in Emacs and put them on their own private Web servers, Google realized that not everyone has access to (or familiarity with) such tools. So, Google provides a Web-based editor (GGE, the Google Gadget Editor), which not only lets people edit their own gadgets via a Web browser, but also provides free storage for gadgets.

I'm going to take a more traditional route to storage in this column, although you're welcome to ignore my example. I'll be putting my gadgets on my Web server (atf.lerner.co.il). To incorporate these gadgets into my iGoogle page, I must go to the My Gadgets gadget and enter the complete URL of the gadget. For example, I stored the above “Hello, world” gadget on my server as rmlgadget1.xml. Thus, I entered the following URL into My Gadgets: http://atf.lerner.co.il/rmlgadget1.xml.

Sure enough, after a moment of loading, I saw “Hello, world!” on my iGoogle screen. Each gadget is displayed inside an iframe, an HTML entity that allows the developer to create content that's independent of its surroundings. Or, thinking about it in a different way, the iframes ensure that gadgets cannot interfere with one another but stay “locked” inside their frames.

It goes without saying that most developers would not be content to produce “Hello, world” programs. Rather, we typically want to do something a bit more substantive.

In order to do that, we need to create a bit more HTML inside the <Content> section. We probably should create some JavaScript that manipulates that HTML as well, given that we have a completely open canvas.

Note that I'm going to modify the original gadget I created, which I named rmlgadget1. Google caches gadgets, which means that once you have loaded one on to your iGoogle page, modifications made to the gadget won't show up. This is when you must fire up your trusty My Gadgets gadget, and uncheck the cached check box for the gadget (in my example, rmlgadget1). Reloading the iGoogle page will reload the gadget from the Web server, allowing you to have a more interactive and productive development experience.

Here's one update that demonstrates how to use JavaScript inside the gadget:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
  <ModulePrefs title="Hello world" />
  <Content type="html">
     <![CDATA[
       <div id="content">Hello, world!</div>
       <script type="text/javascript">
            var element = document.getElementById('content');
            element.innerHTML = "Foo";
       </script>
     ]]>

  </Content>
</Module>

Once again, there's not much content to this widget. We simply use JavaScript and the DOM to modify the contents of a div. So, let's make things a bit more interesting and retrieve the latest headlines from Linux Journal's RSS feed. Then, we can display the first few headlines, even making them linkable:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
  <ModulePrefs title="Reuven's Gadget" />
  <Content type="html">
     <![CDATA[
       <div id="content">Loading feeds...</div>
       <script type="text/javascript">
        var html = '';
        var url = "http://feeds.feedburner.com/linuxjournalcom";
        var callback = function(feed) {

            html += "<ul>\n";
            for (var counter = 0; counter < feed.Entry.length;
counter++)  {
                html += "<li>" + '<a href="' +
feed.Entry[counter].Link + '" ta\
rget="_blank">' + feed.Entry[counter].Title + "</a>"  + "</li>\n";
            }
            html += "</ul>\n";

        _gel('content').innerHTML = html;
        };

        var num_entries = 5;
        var get_summaries = false;
        _IG_FetchFeedAsJSON(url, callback, num_entries, get_summaries);
       </script>
     ]]>

  </Content>
</Module>

The above gadget code begins with the same sort of static code as our previous gadget, although I did change it from saying “Hello, world” to something a bit more useful (“Loading feeds...”), because this text will appear while the feeds are loaded.

The JavaScript in this gadget is somewhat interesting, mostly because it depends on the _IG_FetchFeedAsJSON function, which Google provides to gadget developers. This function takes four arguments, and the first two are mandatory—the URL from which to fetch the arguments and the callback function that should be invoked when the feed is retrieved. For our example, I'm using the RSS/Atom feed URL for Linux Journal as provided by FeedBurner.com. Thus, we will get the list of recent www.linuxjournal.com headlines, as defined by the site administrators.

The callback function, which I've named callback here, is invoked with a single argument, the JSON (JavaScript Object Notation), representing the feed that was retrieved from our URL. That JSON contains an array named Entry, whose elements contain the feed information. Each element contains Title and Link properties, which we will use to construct the output HTML.

When callback is invoked, we first go to FeedBurner.com and retrieve the five most-recent headlines:

_IG_FetchFeedAsJSON(url, callback, num_entries, get_summaries);

Then, we iterate over the elements of Entry, appending them to a variable we've conveniently named html and putting each Title inside an HTML link, which opens the target URL in a new tab or window (thanks to target="_blank"):

       for (var counter = 0; counter < feed.Entry.length;
counter++)  {
           html += "<li>" + '<a href="' +
feed.Entry[counter].Link + '" ta\
   rget="_blank">' + feed.Entry[counter].Title + "</a>"  + "</li>\n";
            }

Finally, we assign our div (the one that starts by saying “Loading feeds...”):

_gel('content').innerHTML = html;

Sure enough, our gadget works very nicely, providing us with a dynamically updated list of headlines from Linux Journal. What could be better?

One of the most interesting characteristics of Google Gadgets is the way in which they are completely self-contained, insulated from the surrounding page and application. As I mentioned previously, this is because each gadget sits inside an iframe, and it undoubtedly was one of the reasons gadgets were used as the basis for OpenSocial.

However, we already can see how this will lead to a situation in which the application, rather than the hosting OpenSocial “container” site, determines the look and feel. This means if you include six OpenSocial applications, each one will have its own look and feel. This is a big difference from Facebook, in which applications are forced, to a large degree, to adhere to Facebook's look and feel, creating a rather pleasant user experience. Time will tell whether this causes problems or whether developers and users will reach a happy medium on this issue.

A separate issue is the fact that each gadget contains only a single page of HTML. Any updates that take place within the gadget, as we saw, happen thanks to JavaScript manipulation of the DOM. This is not a bad thing, and it is becoming increasingly common as Ajax becomes more pervasive among Web developers. However, it may be slightly foreign for developers who are still using the one-page-per-click paradigm.

Google Gadgets are small, self-contained mini-pages written in a combination of XML, HTML and JavaScript. They may be hosted by Google or on your own server, and to date, they primarily have been used for the personalized iGoogle service. However, Google Gadgets now form the foundation of OpenSocial, an open application standard used by social-networking sites other than Facebook. Next month, we will see how to convert our Google Gadget into an OpenSocial application.