The OpenSocial 0.9 draft has been defined. We are awaiting prototypes of all the new features before we declare the draft final. That means that, unless the spec is ambiguous or impossible to implement, the documentation is largely done. The set of changes accepted into 0.9 include some major additions to OpenSocial as a common platform. Given that platforms using OpenSocial touch over 600 million users (source), the changes effect a lot of people. The platform is open, meaning that it is guided by the community instead of by a single entity.

For v.NEXT, you are all invited to participate in the discussion we will continue to have at http://groups.google.com/group/opensocial-and-gadgets-spec/topics?hl=en. We really do need and want more developers to participate. Suggest features you would like to see. Tell the container developers that you love/hate an idea. Participate! A spec cycle lasts 3-4 months. During that time we: propose new features (6-8 weeks); discuss, refine, and vote on proposals (2-3 weeks); write a draft spec (2 weeks); review and vote on the draft (1 week). To be accepted, an item needs at least 5 votes for the feature and no votes against the feature. Because the process is open (as in open source), anyone can participate.

So, what do we have in store for you in 0.9 in terms of accepted proposals? The changes fall in a few different buckets: cleanup from previous iterations, enhancements to existing features, and introduction of brand new items. Oh yes, we are also deprecating some features as well. Note I said deprecating, not eliminating. As such, you shouldn't worry about features being removed. That will happen in the future and you will be warned when it happens.

Over the next couple weeks, I want to spend some time going over the changes that are coming up. In most cases, we build on the platform or simplify things. To give you a taste of what I'll be talking about, here is the list of changes coming in 0.9:

Changes/clarifications to existing features

• Activity Paging: Added a class, opensocial.DataRequest.ActivityRequestFields, that has two values: FIRST and MAX. FIRST specifies the first item to fetch from the activity, MAX indicates how many to retrieve at once.
• Align JS API and REST: The REST spec sees the Address element get updated to understand LATITUDE, LONGITUDE, and TYPE. Why? Not all locations have street addresses. And, the nearest street might be hundreds of miles away. Type is there to make labeling of addresses easier.
• Align Portable Contacts and REST: Add language to the REST spec stating that we will work with the Portable Contacts folks to keep our specifications aligned. They did the same thing in their spec.
• Anonymous Viewer: The spec did not say what the VIEWER ID should be if the VIEWER hasn't logged in. Most of the containers had decided that the value should be -1. Now, the spec will say that too.
• Change to osapi:recipient format: The messaging part of the API did not give a way to indicate if a message was intended for a person (Scott) or a group (Scott's Top Friends). We added a string to the REST API saying that the ID can indicate the type of ID as group or person.
• Clarify timing of callback execution in JS API: In some implementations, the callback might get called before the function to get data had returned. In others, the callback was always called later. This caused buggy behavior when switching platforms. So, in 0.9, we decided that the callback function will not be called until after the existing call stack has completed. (i.e. window.setTimeout(<callback closure>, 0);).
• Implementing IS FRIENDS WITH: The 0.8.1 REST spec didn't say how to figure out how two people are friends. 0.9 will. Here is what we decided:

To determine if two people are friends:

  /people/@me/@self?filterBy=@friends&filterOp=contains&filtervalue=<someUserid>

To find mutual friends between two user IDs

 /people/@me/@friends?filterBy=@friends&filterOp=contains&filterValue=<someuserid>

filterValue can take a specific person identifier or @owner or @viewer

• Radically simplify the Persistence/AppData API: Essentially, once you have a Person object, you can call getAppData(key) to get a specific piece of AppData.
• registerOnLoadHandler: Spec was silent on what happened if the gadgets.util.registerOnLoadHandler was called many times. Now, it says that all functions will be called in the order they were added.
• requestShareApp and requestSendMessage should use IdSpec: These were the only two functions in the existing API that took user IDs as strings instead of an IdSpec. Now, they take an IdSpec instead.
• Resolve Schema with Portable Contacts: A stated goal of Portable Contacts and OpenSocial as that the Person and related objects should be compatible. We worked with the Portable Contacts folks to make sure that are schema is compatible.
• Specify ownership of the page fragment identifier in the spec: The specification didn't say who owns the # portion of the ID. In reality, the containers all own it for various reasons. (See here for how to work around this.)

New Features (that will be the subject of my next series of posts):

• Albums API
• Content Rewriter Feature
• Gadgets Log
• International Date Time Number Formatting
• Lightweight JS APIs
• Limited Invalidation
• Messaging API Changes
• Min age metadata for ModulePrefs
• OAuth Popup
• OSML Tags
• OpenSocial Templates
• Overloading meaning of view
• Proxied Content
• UserPrefs for REST API
• Versioning Applications

I'll work through the features, no more than 1000 words at a time. Some of these will be easy to explain, some more lengthy.

Finally, I want you to know that we are working hard to support these features. Every time we launch new features to better align with OpenSocial, we will broadcast where we are at.