orkut Developer Blog

OpenSocial apps now available to all users

2008-07-18T15:26:00.000-07:00

Posted by Lane LiaBraaten, orkut team

We've finished our rollout of OpenSocial apps to all orkut users, and we've seen more interest in apps than ever before. Several apps experienced extremely high usage, but after utilizing the URL rewriter and other caching techniques the load on their servers returned to manageable levels. During the rollout, we saw over 5 million app installs on orkut and usage of the platform continues to grow. But we're not done yet...

In the next few months, we'll be focused on increasing the capabilities of the platform and enabling developers to build better apps. Among our top priorities are finishing support for OpenSocial v0.8, including the RESTful API, and allowing access to albums and photos by extending the JavaScript API. Please continue to use the public issue tracker to report bugs and star the feature requests that are important to you.

On behalf of the entire orkut team, I'd like to thank all the developers who have contributed to the apps running on orkut. Now that your apps can reach the full set of orkut users, we look forward to seeing what you'll build next.

Happy Coding!

New way of identifying message bundles

2008-07-11T16:55:00.000-07:00

Posted by Jason Cooper, Developer Programs

A recent push introduced a subtle but important distinction concerning how message bundles are specified, and your apps need updating to reflect this change.

Instead of identifying message bundles using language-country combination codes, you must now specify the language code only (pt vs. pt-BR). If you need to distinguish your bundles by country (e.g. U.S. English vs. U.K. English), you can add a 'country' element to your Locale element with the appropriate country code. The article on localization has more information as well as examples.

Message bundles for app meta information such as title and description are still identified using language-country combination codes. This is a bug which should be fixed in a future update. In the meantime, you can specify two Locale elements per language as in the set below. Notice that both reference the same bundle:


<Locale lang="pt" messages="http://www.example.com/pt_ALL.xml"/>
<Locale lang="pt-BR" messages="http://www.example.com/pt_ALL.xml"/>

This will ensure that both your application text as well as its meta information are displayed correctly.

The final push begins tomorrow

2008-07-09T17:15:00.000-07:00

Posted by Jason Cooper, Developer Programs

The big day is almost here! Tomorrow marks the beginning of the final stage of the application roll-out to orkut users, giving you several hours to get your apps in tip-top shape in order to handle the expected traffic increase ahead.

If you haven't already, it is absolutely imperative that you read the Latency Tips for orkut. It presents a number of techniques and best practices that you can take advantage of, even within the next few hours, to get your application up to speed.

Among the techniques listed is the use of Preload elements in your app spec. Preload elements allow for makeRequest responses to be preloaded while the gadget is rendering. If you use a lot of static makeRequest calls in your application (e.g. retrieving a user's high score or a list of gifts that have been sent from your app), taking advantage of pre-loading can make a big difference in the response time of your application. More information on pre-loading is available here.

One other technique that you may find useful is automatic URL rewriting. During preprocessing, orkut can automatically replace the URLs for static content (e.g. JavaScript files, style sheets, images, etc.) with proxied URLs, significantly reducing both the load on your servers and the loading time for your users. While rewriting is automatically enabled in the sandbox, you will have to opt-in in www.orkut.com. Instructions on how to do this are provided here. Make sure to thoroughly test your application if you opt in to rewriting, although you shouldn't run into any problems if you specify absolute URLs to your resources.

As a final note, please make sure that caching is enabled for your application's resources, particularly images and other large files that your app loads frequently. Due to a caching bug that affected many apps last week, you may have opted out of caching completely. This bug was patched last week, and orkut's caching infrastructure now honors both the Cache-Control and Expires headers returned by your application's host with a minimum refresh rate of five minutes. Please make the necessary changes to your server configuration to set your cache to expire at most once per hour (the default duration if no cache control headers are set). Not only will this take some strain off of your own servers, but your users' experience will improve greatly as a result.

We'll be monitoring the performance of your applications. If we see your servers buckle under the increased traffic, we will suspend your application by removing it from the directory and user profiles until your host can be updated to accommodate the traffic. We really don't want to do this, so use the next several hours to read the tips and get your apps ready.

...and we're back!

2008-07-07T19:34:00.001-07:00

Posted by Jason Cooper, Developer Programs

The Orkut sandbox is back to normal.

If you're still experiencing problems, please post in the appropriate thread in the Orkut developer forum.

Happy coding!

Bad, bad server. No donut for you

2008-07-07T14:27:00.000-07:00

Posted by Jason Cooper, Developer Programs

The sandbox is currently being updated, which is preventing all applications from loading (applications are continuing to load as expected on www.orkut.com). We expect things to return to normal fairly soon and will update the blog when the sandbox is back to its normal self. We apologize for any inconvenience in the meantime.

Preparing for the final push...

2008-07-02T10:42:00.000-07:00

Posted by Lane LiaBraaten, orkut team

The orkut team has been hard at work, making improvements to the performance and user experience of the application platform, preparing to complete our launch and enable OpenSocial apps for all users. We're going to perform this final roll out over the course of a few days, starting on July 10th, to help distribute the expected increase in traffic to your applications.

If you haven't already, now is the time to implement some of the caching and performance techniques that will help your servers survive this ramp up of new traffic. Here are a few strategies you should be using:

Render your profile view based on appData, not on data you receive from your server.
Profile views make up the lion's share of application renders. You can drastically reduce the number of requests hitting your server if you store information in appData so that you can render the profile view without pinging your third party server. It's also much faster to request data from the container - so your app will be the first to load on a user's profile.

Let orkut cache images and other static content for you.
You can use getProxyUrl to fetch a URL for the cached version of a static resource. Be sure to re-enable URL rewriting if you previously opted out. Also, be sure to use Cache-Control headers to maximize the benefits of caching.

Use <Preload> tags to fetch data from your server.
You can now send signed requests to your servers before your app is even finished loading—just add the authz parameter to your <Preload> tags. Orkut will also respect the cache headers you include in the response, which can greatly reduce the load on your servers.

You can find details on these and other best practices for performance in the Latency Tips for orkut article. Also, remember that a large percentage of orkut users speak Portuguese, so check out this article on localization.

requestSendMessage now in production

2008-06-26T12:25:00.000-07:00

Posted by Lane LiaBraaten, orkut team

After several weeks of testing on the sandbox, the opensocial.requestSendMessage method, which enables users to send messages to other users straight from your application, has made its way to www.orkut.com.

This method has a quota of 10 invocations per user, per day. This means that a user can use the send message functionality 10 times per day across all apps. If a user enters multiple people in the 'to' field, that counts as a single invocation. Once a user reaches his or her quota, invoking requestSendMessage will result in a 'limitExceeded' error. If this happens, orkut will notify the user that their message wasn't sent.

For a recap of how to use this method, refer to this previous post. As always, please send us feedback in the orkut developer forum and report any issues in the public issue tracker.

Update: Clarified details around users exceeding their quota.

Introducing formal IRC office hours

2008-06-17T16:49:00.000-07:00

Posted by Jason Cooper, Developer Programs

As part of our ongoing effort to offer top-notch support to OpenSocial developers, we're formally introducing reoccurring IRC "office hours." Just point your favorite IRC client to irc.freenode.net and join the #opensocial channel to chat about all things OpenSocial -- container support, the latest and greatest development techniques, upcoming changes to the specification, and more.

Our formal office hour block will be every Tuesday and Thursday from 1:00 p.m. to 3:00 p.m. PST. During these times, one or more Googlers are guaranteed to be available in the #opensocial channel (look for the nicks kurrik, jasonacooper, rohitghatol, and api_dwh). In addition, we'll try to make ourselves available during other days and times as our schedules permit, so feel free to ping us if you see us.

Of course, we'll continue to answer questions in the forum as well, so you can choose the support mechanism that works best for you!

Rewriting returns to the sandbox

2008-06-06T16:07:00.000-07:00

Posted by Jason Cooper, Developer Programs

One technique introduced recently to help combat latency is automatic URL rewriting -- during preprocessing, orkut will automatically replace the URLs for static content (e.g. JavaScript files, style sheets, images, etc.) with proxied URLs.

Yesterday, we pushed a new version of the rewriting mechanism to the sandbox as well as a more granular method of disabling rewriting during testing (when these static resources are likely to be in flux). Once your application is polished and ready for deployment, you should re-enable rewriting so that your app can take advantage of the automatic proxying, which reduces both the load on your servers and the loading time for your users.

To customize rewriting for your test applications, place the following block in your app spec's ModulePrefs element, replacing the [REGULAR_EXPRESSION] blocks with your custom expressions:


<Optional feature="content-rewrite">
  <Param name="include-urls">[REGULAR_EXPRESSION]</Param>
  <Param name="exclude-urls">[REGULAR_EXPRESSION]</Param>
  <Param name="include-tags">[COMMA SEPARATED LIST OF HTML TAG NAMES]</Param>
</Optional>

The first parameter above is where you should place full or partial URLs (using standard regular expression syntax) to be automatically proxied. The second parameter accepts URLs that should be explicitly excluded from the automatic proxying. Finally, the third row contains element names that the preprocessor targets for rewriting.

For example, to disable rewriting completely (for testing only!), you can use the following block. Notice the .* in the second parameter -- this is a common regular expression for matching all characters, meaning that all URLs will effectively be excluded here:


<Optional feature="content-rewrite">
  <Param name="include-urls"></Param>
  <Param name="exclude-urls">.*</Param>
  <Param name="include-tags"></Param>
</Optional>

After your application is polished, you should include all URLs that aren't delivered via a CDN such as Akamai. Since the exclude-urls parameter is applied after include-urls, you can filter these special resources by placing an appropriate expression in 'exclude-urls' -- this will be honored even if you specified .* in the first parameter.

One final note: if you don't include the snippet above, orkut will automatically include all URLs that it encounters as well as all script, link, img, embed, and style elements.

Updated 7/16/2008: Corrected the "include-tags" parameter description. Instead of being a regular expression, this should just be a comma-separated list of tags that should be rewritten. For example:


<Param name="include-tags">img,script,link,embed</Param>

Planned maintenance for app directory

2008-05-28T11:50:00.000-07:00

Posted by Lane LiaBraaten, Developer Programs

We'll be performing maintenance on the app directory this evening, Wednesday, May 28, beginning at 11pm PST (that's Thursday, May 29, at 11:30am India Standard Time). The directory itself will continue to function normally for users, but as a developer you will not be able to submit any new apps during this maintenance period. If you receive an error indicating that your app submission was not successful, please try again on Thursday morning (or later in the evening, if you're in India :)).

New Feature: Disable automatic URL rewriting for easier development

2008-05-27T09:15:00.000-07:00

Posted by Arne Roomann-Kurrik, Developer Programs

In our last post about latency optimizations, we introduced a new feature of the orkut sandbox - automatic URL rewriting for remote content such as JavaScript, CSS, and images. The response to this feature has been favorable, and our users have seen decreased latency and improved application performance across the board.

However, since caching can make development difficult, some developers have asked for a way to turn off this behavior. The orkut team has just pushed a new feature to the sandbox that addresses these requests. Now, if you really need to disable this automatic rewriting, you can use the following code inside the <ModulePrefs> section of your gadget spec:


<Optional feature="content-rewrite">
     <Param name="include">NONE</Param>
</Optional>

Keep in mind that this should only be used to help develop your application. Your production apps should not rely on this feature!

As usual, appending &bpc=1 to the end of any URL you visit will bypass the cache on the rendered page, including rewritten links.

Happy coding!

New users and new interactions

2008-05-14T11:42:00.000-07:00

Posted by Lane LiaBraaten, Developer Programs

We recently enabled OpenSocial apps for new set of users across the globe, increasing traffic by another 10%. Not only does this increase the number of users with access to your apps, it opens up new possibilities for apps with localized features and content. Keep in mind that we expect traffic to increase 5-10 times the current load once we've launched to all users, so start planning to scale now.

Today we enabled opensocial.requestSendMessage on the sandbox, creating a new way for your apps to let users communicate. The messages created with this method will be delivered as email or as orkut messages depending on the user's settings.

Here's some sample code to get you started:


function sendEmail() {
  var params = [];
  params[opensocial.Message.Field.TITLE]="Hola!";
  var body="Como estas?";   
  var message = opensocial.newMessage(body, params);
  var recipient = opensocial.DataRequest.PersonId.OWNER;
  opensocial.requestSendMessage(recipient, message);
};

When invoked, the requestSendMessage method will cause orkut to display a dialog with the title, body, and recipient defined in your code, along with a text area where the user can add text themselves and then click a 'send' button. Note that you can also specify a specific user's OpenSocial ID instead of OWNER or VIEWER.

You can also use VIEWER_FRIENDS or OWNER_FRIENDS for the recipients parameter. In this case the user can determine which of the friends should received the message using an auto-complete friend picker form.

Note that on www.orkut.com each user will be able to send up to 10 messages per day. We'll be more lenient in the sandbox so you can test and tweak your messages.

Happy coding!

Latency optimizations: Feel the need... the need for speed!

2008-05-14T11:06:00.000-07:00

Posted by Arne Roomann-Kurrik, Developer Programs

In the social application space, speed is king. Is your application providing a poor user experience by taking too long to load? The Firebug extension for Firefox has support for measuring the latency of your orkut applications. You can obtain the measurements for your application by loading your application and checking Firebug's "Net" tab to see how long your application takes to load completely.

If you're seeing loading times of:

Less than 5 seconds on the canvas and less than 2 seconds on the profile - your application is doing great!
Between 5 and 10 seconds on the canvas and between 2 and 5 seconds on the profile - your application should be tweaked to reduce latency.
Over 10 seconds on the canvas and over 5 seconds on the profile - you MUST improve the performance of your application.

If your app falls in the latter two categories, we've got some techniques you need to use to ensure a better user experience. Since our last post about reducing application latency, the orkut team has been hard at work identifying areas where application load times can be significantly reduced and has made some improvements to the sandbox. Some of these changes will improve your application latency automatically, and others will require a bit of extra work to take advantage of. All of these techniques will help your applications load faster, reduce the load on your servers, and help increase the stability and reliability of the application platform as a whole.

For a complete list of approaches you can use on orkut to decrease application latency, make sure that you check out the Latency Combat Field Manual, which has been updated to include the approaches listed here. These changes are currently live on the sandbox and will be rolling out to production soon, so be sure to start using the following as soon as possible:

Preload for makeRequest calls
Many applications wait for a registerOnLoadHandler callback before executing a makeRequest call, which slows down render time considerably. To combat this, orkut now allows for an extra parameter in your ModulePrefs which will instruct orkut to make a signed request while the application IFRAME is loading. If your makeRequest call looks like:


var params = {};
params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.JSON;
params[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.SIGNED;
gadgets.io.makeRequest("http://www.example.com", response, params);

You can preload the request by adding a <Preload> tag:


<ModulePrefs title="Demo Preloads" description="Demo Preloads">
  <Require feature="opensocial-0.7" />
  <Require feature="views" />
  <Preload href="http://www.example.com" authz="signed" />
</ModulePrefs>

When your application IFRAME loads, the response from example.com will be available inline in the HTML surrounding your application. When your application executes the makeRequest

call, this content will be returned instantly, without needing to hit your server again. Notice that this approach supports signed requests through the use of the authz parameter, so your data can load fast AND be verifiable.

There are additional things you can do with the element-- make sure that you read the updated Latency Combat Field Manual section on preloads for additional information.

What are the benefits?
Users no longer need to wait for your application to finish loading on orkut before executing a makeRequest call. Orkut will make the request and insert the response directly into the application as it renders your application.

Improved respect for cache headers

Orkut now offers better support for the Cache-Control HTTP header. You have server-side control over how your resources are cached, so be sure to set your headers appropriately for maximum benefit.

The Cache-Control header is best described in the HTTP/1.1 specification but there are some simpler descriptions available as well. If you're not sure about the cache headers your server is currently sending, you can try some publicly available tools to examine the cache headers on your files and see if they need to be tweaked.

Be aware that the Cache-Control header will be examined for all content coming from your server, including XML application specs, responses from makeRequest (both prefetched and not) and proxied images. Be sure to set caching headers for everything!

A note for Apache users: Apache defaults to using Last-Modified and ETag headers to control caching for static files, rather than the recommended Expires and Cache-Control: max-age headers. If you are using Apache, change your cache headers to Expires and max-age.

What are the benefits?
Your server has much more control over how orkut caches its content. You can set a low cache expiration for content that changes often, and a high cache timeout for content that does not change. Caching will become much more efficient once you set the appropriate headers.

Reducing the number of fetches

Some internet browsers (like IE7) will only download two files from a given server at a time, shared amongst all HTML, XML, image, CSS, and JavaScript files. To reduce the number of connections that a user has to make back to your server, consolidate and inline as much code as possible.

If your JavaScript includes look like:


<script src="http://www.example.com/javascript.core.js" type="text/javascript"></script>
<script src="http://www.example.com/javascript.extra.js" type="text/javascript"></script>

You should combine each file into one master JavaScript file:


<script src="http://www.example.com/javascript.all.js" type="text/javascript"></script>

Better yet, inline your code if at all possible:


<script type="text/javascript">
  function1() {
    ...
  };
  ...
</script>

This will save server connections for other assets. Remember that this approach can be used for CSS, as well.

To decrease the number of image files your application needs to load, you can use image spriting to combine all your image files into a single master "sprite" file. Check out A List Apart's CSS Spriting article for a good description of this technique.

Generally speaking, concatenating your files is a great performance improvement you can make. Because of the aggressive caching that orkut performs, even using a relatively slow server-side script to automatically concatenate files will still wind up performing better than separate files (once the automatically concatenated file is cached). Aim for a single CSS and a single JS file in production.

What are the benefits?
This approach keeps the number of server connections low, and reduces the total number of HTTP requests that each user of your application has to make.

Automatic remote file caching
You probably already know how to get proxy URLs for dynamically inserted page elements using the getProxyUrl function. However, this technique does not help cache image, script, or style tags that are directly embedded in the source of your application. Orkut will now rewrite the href attributes on these elements as proxied URLs, meaning that all non-dynamic references to remote content will automatically get the benefit of caching.

If your source contains an image tag which looks like


<img src="http://www.example.com/i_heart_apis.png" />

orkut will render the image tag as


<img src="http://www.gmodules.com/ig/proxy?url=http%3A%2F%2Fwww.example.com%2Fi_heart_apis.png" />

Note that any HTML fetched using makeRequest or otherwise passed through the proxy will also have its links rewritten in this manner. Caching is now automatic throughout your entire application.

What are the benefits?
This approach can dramatically reduce the load on your server for image, CSS, and JavaScript resources that are directly included in your application source, without you needing to change any code at all.

Additional Ideas
You should now have a wealth of techniques to use to speed up your application on orkut. For an updated list of optimizations your applications may use, check out the updated Latency Combat Field Manual. If you want additional suggestions, please check out the YSlow tool for Firebug , which can analyze your application and give suggestions on areas for improvement.

Remember, every little bit counts when you're tuning an application for millions of potential users! Use as many of these techniques as possible to decrease load times and keep your users (and servers) happy. Be sure to join us in the groups or in the #opensocial channel on Freenode IRC if you have further questions.

New wiki article on localization

2008-04-25T10:47:00.000-07:00

Posted by Jason Cooper, Developer Programs

With stage one of the orkut launch process behind us, it's time to start looking forward to the even bigger stage ahead—Brazil. Building applications for Brazilian users poses a special challenge for non-native developers. Since most of the Brazilian user base speaks Portuguese, most apps will have to be localized or translated so they can be understood.

Fortunately, the gadget specification (which all OpenSocial apps use) makes it easy to define localizations without duplicating any application logic using a mechanism called message bundles. To help you get started, we have released a new article on the OpenSocial wiki specifically on techniques you can use to localize your apps not only for Brazilian Portuguese but any language or country you please.

Enjoy! As always, if you have any questions, please stop by the discussion forum.

New directory on sandbox

2008-04-24T16:47:00.000-07:00

Posted by Lane LiaBraaten, Developer Programs

We're pushing a new release to the sandbox today that includes a new component for running the app directory. The new directory system will provide dynamic ranking of apps, based on a number of factors including the locale of the user and the popularity of the app. Like search results on google.com, the order of apps will be determined by the directory's ranking algorithm and we won't have the ability to move individual apps around within the directory.

We're aiming to ship this new directory system to www.orkut.com next week. In the meantime, we'll be adding apps to the directory on the sandbox. The new directory speeds up our review process, so you'll start seeing a lot of new apps in the directory on the sandbox soon. We don't plan to add any new apps to the directory on www.orkut.com until we move the new directory system from the sandbox into production. At that point, any apps in the sandbox directory will go live in production.

Last but not least, today's release also includes a couple fixes to requestNavigateTo that popped up in the last few days. If you're still seeing problems, please file an issue.

...and we're back!

2008-04-21T18:20:00.000-07:00

Posted by Arne Roomann-Kurrik, Google Developer Programs

The Orkut sandbox is back to normal.

If you're still experiencing problems, please post in the appropriate thread in the Orkut developer forum.

Happy coding!

Bad, bad server. No donut for you

2008-04-21T18:03:00.000-07:00

Posted by Lane LiaBraaten, Developer Programs

Well, it's not "the donut error," but the sandbox is currently serving up 502's while we perform some updates. We expect things to return to normal later this evening. Please stay tuned for further updates.

Chat with the team this week!

2008-04-21T14:20:00.000-07:00

Posted by Jason Cooper, Developer Programs

Now that the orkut development platform is live in India and new apps are being added to the directory daily, we want to make sure any questions you have related to the multi-stage launch process and app development in general are answered.

With this objective in mind, we'll be holding IRC office hours this week. Several members of the OpenSocial team will be available in the official OpenSocial IRC channel this coming Tuesday from 10:00 a.m. to 3:00 p.m. PDT to field any questions you have related to the orkut platform and OpenSocial in general.

To recap:
What: IRC office hours
When: April 22nd, 10:00 a.m. - 3:00 p.m. PDT
Where: irc.freenode.com#opensocial

See you there!

Latency lurks around every corner...defend yourself!

2008-04-18T10:16:00.000-07:00

Posted by Lane LiaBraaten, Developer Programs

Over the past few weeks, we've been studying the behavior of apps on orkut and have discovered several ways to make them faster. We've made a few enhancements on our side that have improved response time considerably, like pre-fetching data requests—essentially retrieving the data your app will need before it's requested.

In addition to the efforts we've undertaken, there are optimizations you can make in your apps to improve their load times. There are some general web development best practices that are especially helpful in the OpenSocial context, and other techniques that are specific to OpenSocial and orkut, like using gadgets.io.proxyUrl to access cached resources rather than hitting your own server for each request.

Send your app through boot camp with this Latency Combat Field Manual and get your code up to speed.

Live in India

2008-04-16T20:34:00.000-07:00

Posted by Jason Cooper, Developer Programs

Last month's prelaunch testing of the orkut developer platform brought a small set of third-party applications to less than 1% of orkut users. After implementing various improvements, tweaks, and fixes, we are moving into the first stage of the official rollout process by announcing the platform's availability in India, which represents about 10% of the orkut user base.

To commemorate the launch, five new applications are being added to the directory alongside the 15 from the prelaunch testing period. Early next week, after we have had an opportunity to assess the platform for several days, we will begin adding more applications to the directory. As noted previously, apps originally submitted on or before 2/15 will get first priority for review. All others are being reviewed on a first-come, first-serve basis, so submit yours soon!

Several members from the OpenSocial developer support team will be available in the official OpenSocial IRC channel (irc.freenode.com#opensocial) next week to chat about the orkut platform and development in general. Stay tuned to this blog for an official date and time, which we'll make available soon.

Developer Guidelines

2008-04-11T19:08:00.000-07:00

Posted by Amar Gandhi, Group Product Manager

We just published some orkut developer guidelines that include examples of good practices and give guidance on how to build a successful OpenSocial app for orkut.

The guidelines also include our monetization policies. The short version--developers do not need to share any revenue with orkut.com. If you're using AdSense (by Google) then then usual AdSense terms apply.

Launching to 10% of users in about a week

2008-04-10T10:22:00.000-07:00

Posted by Amar Gandhi, Group Product Manager

We're now about a week away from making OpenSocial apps available to millions of users in India, corresponding to 10% of all orkut users. With this update we also want to increase the number of apps included in the directory. As we mentioned last week, we've created a new app submission page.

Please note that all apps must be submitted through this page to be included in the directory. Even if you have submitted your app previously, you still need to resubmit your app through this new page and agree to the Developer Terms of Service for orkut.

As we mentioned before, developers who submitted their app on or before 2/15 will get first priority for review. Other than these early birds, we'll be reviewing apps on a first come, first serve basis. Right now we're expecting it to take 1-2 weeks after submission for an app to show up in the directory, but this will depend on the volume of apps we receive. If your app is not approved for some reason, you will be notified by email.

Thank you for your patience as we finalized the UI, API and user experience during the pre-launch testing period. Please write to us if you have additional questions or concerns.

Update on the launch rollout plan

2008-04-04T10:09:00.000-07:00

Posted by Amar Gandhi, Group Product Manager

We've discovered and fixed numerous bugs during prelaunch testing and have been working on a number of UI improvements based on developer and user feedback. You will be able to see these changes on the sandbox soon.

The launch rollout will occur in two stages. We will first make apps available to 10% of users. Once we have determined that the platform is working well, we will make an update to the directory and continue rolling out to the rest of orkut users.

Before the first stage of the rollout, we'll contact developers who submitted their apps by 2/15 so we can include their apps in the first stage and will make available a new submission page where anyone can submit his/her app. We will add these submitted apps to the directory on a first come, first serve basis before and during the first stage.

Stay tuned for new developer guidelines and the new submission page. One week before we begin the first stage of the rollout, we will announce it here and link to the new submission page so everyone has time to prepare.

Upcoming changes to signed makeRequest parameter names

2008-03-26T13:05:00.000-07:00

Posted by Arne Roomann-Kurrik, Google Developer Programs

When a gadget initiates a signed makeRequest call on an OpenSocial container, the OpenSocial specification indicates that the container should include certain pieces of information if available, such as the OWNER and VIEWER IDs. What the spec does not define, however, is the parameter key under which these values must be passed.

Because of this, MySpace currently passes the parameters under the keys opensocial_viewer_id and opensocial_owner_id, while orkut uses opensocial_viewerid and opensocial_ownerid. This means that developers writing applications intended to run in both MySpace and orkut must include conditional server code to check for different parameter names, depending on where the request originates.

Sometime in the next few days, orkut will be implementing a simple fix for this problem so that applications have an easier time working across both containers. When the fix goes live, orkut's sandbox will start sending opensocial_viewer_id and opensocial_owner_id parameters when making signed requests. If you are currently validating signed requests on the sandbox, you will need to change your code.

We will post again before the fix is pushed with an exact time that this change will take place. For the time being, please make the appropriate changes to your code to prepare for the new orkut parameter names. Thankfully, this should be a simple change for most developers.

For more information, see this post in the OpenSocial and gadgets specification discussion group.

Sandbox updates...

2008-03-21T13:18:00.000-07:00

Posted by Lane LiaBraaten, Developer Programs

We just fixed a bunch of issues on the sandbox:

51 Access to the application's ID
79 adjustHeight only works for first app on profile page
98 requestNavigateTo("canvas") from profile goes to a different app's canvas view
100 gmodules proxy doesn't support gzip data
103 POST data in signed makeRequest calls is not used in generating the signature base string
104 Prototype library interferes with OpenSocial API
107 gadgets.json.parse throwing exceptions

Note that the fix for issue 103 brings orkut into compliance with oauth's parameter signing algorithm, but requires you to update the server side code that verifies signed requests.