Originally posted to the Google Apps Developer blog

Posted by Edward Jones, Software Engineer, Google Apps Script and Wesley Chun, Developer Advocate, Google Apps

Have you ever wanted a server API that modifies cells in a Google Sheet, to execute a Google Apps Script app from outside of Google Apps, or a way to use Apps Script as an API platform? Today, we’re excited to announce you can do all that and more with the Google Apps Script Execution API.

The Execution API allows developers to execute scripts from any client (browser, server, mobile, or any device). You provide the authorization, and the Execution API will run your script. If you’re new to Apps Script, it’s simply JavaScript code hosted in the cloud that can access authorized Google Apps data using the same technology that powers add-ons. The Execution API extends the ability to execute Apps Script code and unlocks the power of Docs, Sheets, Forms, and other supported services for developers.

One of our launch partners, Pear Deck, used the new API to create an interactive presentation tool that connects students to teachers by converting slide decks into interactive experiences. Their app calls the Execution API to automatically generate a Google Doc customized for each student, so everyone gets a personalized set of notes from the presentation. Without the use of Apps Script, their app would be limited to using PDFs and other static file types. Check out the video below to see how it works.

Bruce McPherson, a Google Developer Expert (GDE) for Google Apps, says: “The Execution API is a great tool for enabling what I call ‘incremental transition’ from Microsoft Office (and VBA) to Apps (and Apps Script). A mature Office workflow may involve a number of processes currently orchestrated by VBA, with data in various formats and locations. It can be a challenge to move an entire workload in one step, especially an automated process with many moving parts. This new capability enables the migration of data and process in manageable chunks.” You can find some of Bruce’s sample migration code using the Execution API here.

The Google Apps Script Execution API is live and ready for you to use today. To get started, check out the developer documentation and quickstarts. We invite you to show us what you build with the Execution API!

Cross-posted from the Geo Developers Blog

By Mark McDonald, Google GeoDevelopers Team

We recently announced the launch of the data layer in the Google Maps JavaScript API, including support for GeoJSON and declarative styling.  Today we’d like to share a technical overview explaining how you can create great looking data visualizations using Google Maps.

By Doug Fritz, Creative Lab

Today we’re sharing a small open source project called Tailbone that lets developers read and write to the Google App Engine Datastore using JavaScript. We’re hoping that it makes App Engine a bit more accessible to developers who aren’t familiar with Python, Java or Go, or prefer not to use them.

I share an office with three creative programmers who work almost entirely in HTML5 and JavaScript. An important part of our work is writing server-side code for new projects that read or write data to to the App Engine Datastore or use Google accounts to store authenticated user-specific information. To make that process easier for my JavaScript-fluent colleagues, I created Tailbone to act as a RESTful API for an app’s Datastore.


To get started, you still have to install App Engine’s SDK and Python, but after that you’re all set. We’ve written a detailed tutorial that guides you through the installation and an example app for creating an authenticated profile page with an editable name and photo.

It’s my hope that Tailbone makes App Engine a little bit less intimidating for people who don’t have much experience with server-side coding. I know there are a few in my office. If there are any others out there, this is for you.


Doug Fritz is a programmer with the Creative Lab’s Data Arts Team. He thinks large amounts of data taste slightly purple and strongly wishes the government used bugzilla.

Posted by Scott Knaster, Editor

This guest post was written by Tal Raviv, CTO of Ecquire

Even though the words "browser extension" connote a one-trick feature, today’s browser extensions allow developers to accomplish some pretty amazing things. Entire companies are being funded and sold as extensions and providing serious value to users.

Here’s how you can make your browser extension a formidable product.

1. Use Your Superpowers

Developing an extension gives you advantages you may not have been aware of. Think of your extension as an abnormally powerful front end. I'll name a few features we've especially enjoyed:

• Let your users install very slickly directly from your home website to increase conversions.
• List on the Chrome Web Store for tens of thousands of free impressions. (Tip: For maximum exposure and traffic, invest time in beautiful graphic assets.)
• Use localStorage as a super-easy store. Unlike in regular web applications, localStorage for extensions remains untouched even if users clear their cookies. (For more structured, asynchronous, client-side storage of large amounts of objects, take a look at IndexedDB.)
• Let Chrome sync your extension across devices, including data you store in chrome.storage.sync.

Extensions are your chance to hack with any site you've wanted to improve beyond the limits of their API. There are many more very powerful advantages browser extensions have - these are just the lesser known ones.

Check out examples and look at what other apps (even silly ones) have done. If you find yourself asking “how did they do that?”, check out the source code.

2. Know What's Going On Inside Your App

Because extensions are front ends on steroids, you have your pick of almost any web analytics software you choose. We recommend choosing an event-based, not a page view-based model because the definition of a page view is hard to interpret in most extensions. Instead, track specific interactions.

We chose Mixpanel, but there's an official Chrome tutorial on using Google Analytics in an extension. The principles of implementation are the same no matter what you choose.

Solid analytics help you answer questions about what's going on inside your app using hard data instead of intuition and opinions. It will also undoubtedly reveal a few unexpected surprises about user behavior.

3. Connect to Third-Party APIs

Good apps avoid reinventing the wheel, and great apps connect users to the services they already like using. Extensions can request permission to connect with any domain. Just because you're an extension doesn't mean you can't use OAuth to authorize those requests.

If your extension has a server backend, then fantastic, you have plenty of resources to help you. If you want to directly make requests from the user's computer, that is completely possible. The initial handshake and exchange of access token is done from a light server, but after that you can save the tokens locally. This allows your extension to run all of its interactions client-side if you'd like to keep things simple.

4. Make Money

Accepting credit cards and making financial transactions via an extension can be just as ironclad and secure as anywhere else. There's no shortage of billing management services that provide hosted payment pages and APIs.

Simply direct users to secure hosted payment pages to accept credit card information, letting the billing service deal with compliance. We use Recurly, which conveniently allows our users to use coupon codes, receive invoices by email, and manage their billing info directly, saving us even more development time and headache.

Hosted payment pages may be simple to implement, but they are pretty powerful (see also Chargify and CheddarGetter). They allow very specific management of your paying customers. Hosted payment pages can make your extension aware of the user's subscription status, to deactivate or activate as appropriate. Your customers’ payment statuses can be accessed with APIs behind the scenes throughout the lifetime of your extensions.

If you prefer a super-streamlined flow for your customers - one where they potentially do not need to enter their credit card information - using a hosted payment page from Paypal or the recently announced Google Wallet for digital goods are your best bets for maximum coverage and quickest checkout.

Using hosted payment systems affords maximum functionality with the least amount of coding and testing - or any server-side billing logic. Most importantly, you have peace of mind that your customer's financial information is secure and compliant. No compromises.

5. Use Frontend Frameworks

Anywhere there's JavaScript, you can use JQuery, BackboneJS and CoffeeScript: any JS library or plugin you love. This applies across the extension architecture, from injected UI in content scripts to any background code. The entire platform is web frontend - you can run anything you would use in a web application.

6. Test All the Freaking Time

Okay, I admit it's a more fun motto to say than to do, but if you're a TATFTer, I have good news for you. Adrian Unger provides a how-to on using Jasmine BDD in browser extensions even in the sub-cockles of your content scripts, even in the context of a live, logged-in webpage.

Peace of mind about your code is important, but it's even more crucial in extensions where you don't control the webpages you may be injecting into. You can use Jasmine to assert that the DOM of your target web sites hasn't changed too much and that your code is still valid out in the wild web.

In summary, just when you thought you knew everything you could do on the web, new doors open up. This is just a small taste of our lessons learned about what puts browser extensions in the league of extraordinary platforms. Like any new platform, I can’t even imagine the innovation that has yet to launch.


Tal Raviv is the CTO of Ecquire, a maker of CRM workflow automation software. Capture contacts from anywhere and Ecquire puts it in the right account for you. Read Tal’s guides on Chrome development and startup experiences on the Ecquire blog.

Posted by Scott Knaster, Editor

Marcin

Aaron

By Aaron Wheeler, Senior User Experience Prototyper, and Marcin Wichary, Senior User Experience Designer

Cross-posted with the Chromium Blog

It took approximately 2000 years for the original Rosetta Stone to be discovered, which helped translate the Egyptian Hieroglyphs. We couldn’t wait that long to bridge the Dart and JavaScript worlds, so today we are releasing the JavaScript to Dart Synonym app.

Like most web developers, we are familiar, comfortable, and productive with JavaScript. We were curious about Dart, and thanks to a recent Dart hackathon, we had the chance to play with the language and libraries. The problem was, as JavaScript developers, we didn’t know how to map common JavaScript idioms to Dart. Hence the idea for this synonym app was born.

We started with the basics that every JavaScript and jQuery developer knows: variables, arrays, functions, classes, DOM manipulation, and many more. Then, with the help of the Dart team, we recorded the corresponding Dart versions of each idiom. To practice what we learned, we wrote this app with Dart.


We hope our app that maps between JavaScript and Dart eases your introduction to Dart and gives you a sense of where the project is going. We know the team is eager to hear your feedback. Don’t hesitate to join the conversation or file a new issue for either Dart or the Synonym app. And remember, Dart isn’t set in stone, so your feedback counts.


Aaron Wheeler is a user experience prototyper working on special projects that go beyond the Web. He balances design and engineering outside of work as well, splitting time between artistic pursuits and bicycle maintenance.

Marcin Wichary is a user experience designer, currently working on the Chrome browser and thinking of the future of the Web platform. He also occasionally codes interactive homepage doodles, such as Pac-Man and Stanislaw Lem.

Posted by Scott Knaster, Editor

Brendan

Antonio

By Brendan O’Brien and Antonio Fuentes, Google Developer Team

Today we reached another milestone in our efforts to provide infrastructure and tools to make it easier for developers to use Google APIs: we have released the Google APIs Client Library for JavaScript in Alpha. This client library is the latest addition to our suite of client libraries, which already includes Python, PHP, and Java.

This compact and efficient client library provides access to all the Google APIs that are listed in the APIs Explorer. The client library is also flexible, supporting multiple browser environments including Chrome 8+, Firefox 3.5+, Internet Explorer 8+, Safari 4+, and Opera 11+. In addition, the JavaScript client library supports OAuth 2.0 authorization methods.

You can load the client library using the following script tag:

<script src="https://apis.google.com/js/client.js?onload=CALLBACK"></script>

Loading an API and making a request is as easy as executing:

gapi.client.load('API_NAME', 'API_VERSION', CALLBACK);

// Returns a request object which can then be executed.
// METHOD_NAME is only available once CALLBACK runs.

var request = gapi.client.METHOD_NAME(PARAMETERS_OBJECT); 
request.execute(callback);

You can use the APIs Explorer to check all the methods available for an API, as well as the parameters for each method. For instance, use the above syntax with the plus.activities.search method of the Google+ API to query activities:

<!DOCTYPE html>
<html>
  <head>
  </head>

  <body>
    <script type="text/javascript">

function init() {

  // Load your API key from the Developer Console
  gapi.client.setApiKey('YOUR_API_KEY');

  // Load the API
  gapi.client.load('plus', 'v1', function() {
      var request = gapi.client.plus.activities.search({
          'query': 'Google+',
            'orderby': 'best'
            });

      request.execute(function(resp) {
          // Output title
          var heading = document.createElement('h4');
          heading.appendChild(document.createTextNode(
            resp.title));
          var content = document.getElementById('content');
          content.appendChild(heading);

          // Output content of the response
          if (!resp.items) {
            content.appendChild(document.createTextNode(
              'No results found.'));
          } else {
            for (var i = 0; i < resp.items.length; i++) {
              var entry = document.createElement('p');
            entry.appendChild(document.createTextNode(
              resp.items[i].title));
              content.appendChild(entry);
            }
          }
        });
    });
 }
    </script>
    <script src="https://apis.google.com/js/client.js?onload=init"></script>

    <div id="content"></div>
  </body>
</html>

To try this yourself, sign up in the Google APIs console or refer to the documentation on acquiring and using a developer key in the Google+ API.

The Google APIs Client Library for JavaScript is currently in Alpha, which means that we are actively developing it, but wanted to get the library in your hands as soon as possible, and we welcome any feedback to make the code better. While you can use the current library to start writing code, you should use caution when writing production code as library code changes may break your application. We are working hard to upgrade this release to Beta and beyond soon, and to release even more client libraries.

To get started, visit the JavaScript Client Library documentation page. We also welcome your feedback, which you can provide using the JavaScript client group.


Brendan O'Brien is a Software Engineer for the Browser Client group at Google. Prior to working on JavaScript APIs he was a frontend engineer for iGoogle. He is passionate about JavaScript and enjoys building web applications.

Antonio Fuentes is a Product Manager for the Google API Infrastructure group. He has experience launching products in the cloud computing, infrastructure, and virtualization space.

Posted by Scott Knaster, Editor

By Dominic Szablewski, creator of the Impact Game Engine

This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.


Impact is a JavaScript game engine that uses the HTML5 Canvas and Audio elements for graphics and sound, instead of relying on any browser plugins. Impact's main focus is on classic 2D games. Examples include the Biolab Disaster Jump'n'Run game and the Z-Type Space Shooter. These games, like many other 2D games, draw sprites in front of multiple background layers.


Each background layer is drawn from a tileset, an image containing all the individual building blocks, and a tilemap, a 2D array that tells the renderer where to draw each of these tiles. Similarly, sprites are drawn from an animation sheet, an image with all the animation's frames.

This technique has proven so efficient and flexible that it was enforced in hardware on early game consoles: the Super Nintendo could not do anything other than draw tiled background maps and sprites. There was no way to directly access single pixels on the screen.

The HTML5 Canvas element is perfectly equipped for these kinds of games. Most importantly, the Canvas API's drawImage() method allows us to draw only a certain part of a tileset or animation sheet to the screen. In Impact, however, you don't have to deal with any of the Canvas API methods directly. Instead, you specify your tilemaps and animation sheets and let the engine handle the details.

This is how you'd create an animation from an animation sheet:

// Each animation frame is 16x16 pixels
var sheet = new ig.AnimationSheet( 'player.png', 16, 16 );

// This creates the "run" animation: it has 6 frames (the 2nd row 
// in the image), with each one being shown for 0.07 seconds
var run = new ig.Animation( sheet, 0.07, [6,7,8,9,10,11] );

Similarly, here's the code needed to create and draw a background layer:

// Create a 2D tilemap
var map = [
 [5, 3, 4],
 [2, 7, 1],
 [6, 0, 3]
];

// Specify a layer with a tilesize of 16px and our tilemap
var layer = new ig.BackgroundMap( 16, map, 'tileset.png' );
layer.draw();

You don't have to create these tilemaps by hand. Impact comes with a powerful level editor called Weltmeister, which makes it easy to draw background layers and position your entities (non-static objects in the game world) in your levels.


When drawing on a Canvas, the performance is mostly bounded by the number of draw calls. It is far more efficient to draw one or two very large images than to draw several hundred small ones. This means that drawing background layers tile by tile can be quite slow, especially on mobile devices.

The Impact engine therefore has a special "pre-render" mode that you can enable on background layers. This mode will first draw the tilemap into large chunks of 512x512 pixels when loading a level, and then use these chunks to fill the screen instead of drawing the layer tile by tile. With this technique, you can get good frame rates even for fast-paced games on Android and iOS devices.

Impact also handles sound, input, timing, and much more for you. It's by no means a game engine that can do everything – and it doesn't try to be one – but it's very good at the things it can do.


Come see Impact in the Developer Sandbox at Google I/O on May 10-11.

Dominic Szablewski is the creator of the Impact Game Engine. He recently finished his Bachelor Thesis about HTML5 Gaming and now lives the dream by selling Impact and making games.

Posted by Scott Knaster, Editor

This post is by Roland Steiner of the Chrome Team. Roland works mainly on layout and rendering for Chrome and WebKit. An Austrian native, Roland has ventured far and made Tokyo his second home. -scottk

Many web applications allow users not just to edit plain text, but also to embellish it – making it bold or underlined, adding bulleted lists or images. For example, think of online document or blog editors, or rich e-mail apps. JavaScript provides various APIs you can use to implement these apps.

Unfortunately, while these APIs are largely defined the same in modern browsers, the results often differ. To document the current state of all this, we have set up a new rich text editing test suite as part of the larger browserscope framework.

Let’s look at how a region of text, such as a <div>, can be marked as editable by adding the contenteditable attribute:

<div contenteditable="true"> ...some content... </div>


You can then manipulate the content with simple calls:

document.execCommand("formatting command", showUI, parameter)

For example, you can set the color of the selected text to red with this call:

document.execCommand("forecolor", false, "red")

Although this command works well on most browsers, different browsers implement different subsets of formatting commands, and even common commands often produce varying HTML structures.

There are other APIs that affect selection and cursor movement, or allow querying of the current state, and those, too, are often implemented differently.

Our new test suite tries to capture all currently implemented commands and APIs, and runs them on varying initial HTML content and within various containers. The suite already contains well over 1,000 tests.


We don’t want to stop there. We intend to grow the suite and incorporate external feedback and suggestions so we can arrive at a common set of editing functions. We hope this can then serve as a common reference, not only for browser implementers, but also for web developers.

To achieve this goal, we would like input from anyone interested in this topic, including those with past complaints about bugs and incompatibilities in this area.

For suggestions, criticism, and general discussion on the suite and tests, please send feedback to the browserscope mailing list at [email protected].

If you’ve used Google Search recently, you may have noticed a new feature that we’re calling Instant Previews. By clicking on the (sprited) magnifying glass icon next to a search result you see a preview of that page, often with the relevant content highlighted. Once activated, you can mouse over the rest of the results and quickly (instantly!) see previews of those search results, too.

Adding this feature to Google Search involved a lot of client-side Javascript. Being Google, we had to make sure we could deliver this feature without slowing down the page. We know our users want their results fast. So we thought we’d share some techniques involved in making this new feature fast.

JavaScript compilation

This is nothing new for Google Search: all our Javascript is compiled to make it as small as possible. We use the open-sourced Closure Compiler. In addition to minimizing the Javascript code, it also re-writes expressions, reuses variables, and prunes out code that is not being used. The Javascript on the search results page is deferred, and also cached very aggressively on the client side so that it’s not downloaded more than once per version.

On-demand JSONP

When you activate Instant Previews, the result previews are requested by your web browser.There are several ways to fetch the data we need using Javascript. The most popular techniques are XmlHttpRequest (XHR) and JSONP. XHR generally gives you better control and error-handling, but it has two drawbacks: browsers caching tends to be less reliable, and only same-origin requests are permitted (this is starting to change with modern browsers and cross-origin resource sharing, though). With JSONP, on the other hand, the requested script returns the desired data as a JSON object wrapped in a Javascript callback function, which in our case looks something like

google.vs.r({"dim":[302,585],"url":"http://example.com",ssegs:[...]}).

Although error handling with JSONP is a bit harder to do compared to XHR (not all browsers support onerror events), JSONP can be cached aggressively by the browser, and is not subject to same-origin restrictions. This last point is important for Instant Previews because web browsers restrict the number of concurrent requests that they send to any one host. Using a different host for the preview requests means that we don’t block other requests in the page.

There are a couple of tricks when using JSONP that are worth noting:

• If you insert the script tag directly, e.g. using document.createElement, some browsers will show the page as still “loading” until all script requests are finished. To avoid that, make your DOM call to insert the script tag inside a window.setTimeout call.
• After your requests come back and your callbacks are done, it’s a good idea to set your script src to null, and remove the tag. On some browsers, allowing too many script tags to accumulate over time may slow everything down.

Data URIs

At this point you are probably curious as to what we’re returning in our JSONP calls, and in particular, why we are using JSON and not just plain images. Perhaps you even used Firebug or your browser’s Developer Tools to examine the Instant Previews requests. If so, you will have noticed that we send back the image data as sets of data URIs. Data URIs are base64 encodings of image data, that modern browsers (IE8+, Chrome, Safari, Firefox, Opera, etc) can use to display images, instead of loading them from a server as usual.

To show previews, we need the image, and the relevant content of the page for the particular query, with bounding boxes that we draw on top of the image to show where that content appears on the page. If we used static images, we’d need to make one request for the content and one request for the image; using JSONP with data URIs, we make just one request. Data URIs are limited to 32K on IE8, so we send “slices” that are all under that limit, and then use Javascript to generate the necessary image tags to display them. And even though base64 encoding adds about 33% to the size of the image, our tests showed that gzip-compressed data URIs are comparable in size to the original JPEGs.

We use caching throughout our implementation, but it’s important to not forget about client-side caching as well. By using JSONP and data URIs, we limit the number of requests made, and also make sure that the browser will cache the data, so that if you refresh a page or redo a query, you should get the previews, well... instantly!

By Matías Pelenur, Instant Previews team

(Cross-posted from the Google Web Toolkit blog)

In early August, Google acquired Instantiations, a company known for its focus on Eclipse Java developer tools, including GWT Designer. We're happy to announce today that we're relaunching the following former Instantiations products under the Google name and making them available to all developers at no charge:

• GWT Designer
  Powerful Eclipse-based development tools that enable Java developers to quickly create Ajax user interfaces using Google Web Toolkit (GWT)


• CodePro AnalytiX
  Comprehensive automated software code quality and security analysis tools to improve software quality, reliability, and maintainability


• WindowBuilder Pro
  Java graphical user interface designer for Swing, SWT, GWT, RCP, and XWT UI frameworks


• WindowTester Pro
  Test GUI interactions within Java client rich applications for the SWT and Swing UI frameworks

Now that these products are available again, we hope you’ll start using them within your GWT projects. Meanwhile, our next step is to more deeply unify them into the GWT family of tools by blending the fantastic Instantiations technology into the Google Plugin for Eclipse (GPE). So, there’s much more to come, including things we’re pretty sure you’ll like, such as UiBinder support in GWT Designer.

You can download any of the tools from the GWT download page. If you have questions or comments we’d love to hear from you. The best place to discuss the tools above is at http://forums.instantiations.com. As always, continue to discuss GWT and GPE at the main GWT Group.

We would love to stay in better touch with you as we have more news about how we are integrating the Instantiations products into the Google Web Toolkit suite. Sign up if you’d like to receive email updates on these products and other developer tools.

By Bruce Johnson, Google Developer Team

The Chrome Developer Tools are great for debugging HTML, JavaScript and CSS in Chrome. If you're writing a webpage or even a web app for the Chrome Web Store, you can inspect elements in the DOM, debug live JavaScript, and edit CSS styles directly in the current page. Extensions can make Google Chrome an even better web development environment by providing additional features that you can easily access in your browser. To help developers like you, we created a page that features extensions for web development. We hope you’ll find them useful in creating applications and sites for the web.


For example, Speed Tracer is an extension to help you identify and fix performance issues in your web applications. With Speed Tracer, you can get a better idea of where time is being spent in your application and troubleshoot problems in JavaScript parsing and execution, CSS style, and more.


Another useful extension is the Resolution Test that changes the size of the browser window, so web developers can preview websites in different screen resolutions. It also includes a list of commonly used resolutions, as well as a custom option to input your own resolution.


With the Web Developer extension, you can access additional developer tools such as validation options, page resizing and a CSS elements viewer; all from an additional button in the toolbar.


Another extension you should check out is the Chrome Editor that allows you to easily code within your browser, so you don’t have to flip between your browser and code editor. You can also save a code reference locally to your computer for later use.

These are just a few of the extensions you can find in our extensions for web development page. You can also look for more in the extensions gallery.

By Koh Kim, Google Chrome Team

Earlier today Meebo announced Extended Authentication (XAuth), an open platform that makes it possible for users to bring their preferred services with them across the web.



To learn more about XAuth and why we're among the supporters of this technology, check out our post on the Social Web Blog.



From a technical perspective, we wanted to offer you some additional insights into how this technology works.



If you visit Meebo's XAuth page, you should see an array of logos:





When this page loaded, it requests the list of services that have been registered with XAuth by making an HTML5 window.postMessage request to xauth.org. As you can see in the graphic, no active sessions were detected.



When the user clicks through to one of the linked demo pages — we'll use googxauthdemo.appspot.com in this case — the same JavaScript is loaded from xauth.org. When the user successfully authenticates, some basic information is pushed to the browser's HTML5 localStorage:This information — that the user has an active session at googxauthdemo.appspot.com — is now available to any site on the web (because extend: ["*"] uses the wildcard case to make this information world-readable; providers can also choose to restrict access to this information to certain domains or partners).



Upon returning to meebo.com/xauth, the page requests the list of active sessions from XAuth, and passes the browser an array of domains that the browser will match against the local storage for xauth.org:

The major performance and scalability benefits of this design are a result of the single HTTP request made to xauth.org to determine which services are currently active, rather than one-request-per-domain. The request and response are also purely client-side, so there's no waiting for a server to look up anything in a database — and the XAuth JavaScript files get cached after they are first retrieved, making XAuth overall very efficient.



Once the tokens are retrieved the program iterates through them looking for matches, and then modifies the interface according the service token discovered, like this:

In this way, site publishers can detect a user's set of active and preferred services, or request a subset of known services, and present only those services which are known to be currently active. In practice, the list of services provided at any given time by xauth.org should not be considered exhaustive, but instead a suggestion for how to prioritize complex service selection dialogs and interfaces, like those known as "NASCAR" interfaces.



For more technical information about XAuth, please read the spec, or visit the informational page on xauth.org.



Posted by Chris Messina, Social Web Team