MySpace Developer Team News and Announcements : OpenSocial

OpenSocial State of the Union on May 12th

Chris Cole — Wed, 20 Apr 2011 23:25:00 GMT

It's hard to believe another year has passed. As such, it's time for another State of the Union for OpenSocial. OpenSocial has grown and changed quite a bit over the last year. No longer is it just a platform for a few social networks to allow third-party games. OpenSocial has continued to evolve into uses as a general purpose integration framework. It's seen broad adoption in the Enterprise by the likes of IBM, Oracle, Jive Software, and many others. Myspace has also open sourced large pieces of our OpenSocial platform as Project Negroni.

Come join us and many others at the OpenSocial State of the Union on May 12th (just after Google IO). It's going to be held at the Google San Francisco office. Looking forward to seeing you there. Register for OpenSocial SOTU

Open sourcing the Myspace gadget renderer

Chris Cole — Tue, 07 Dec 2010 17:03:00 GMT

Myspace has always been committed to open standards and the open Internet. The Myspace Developer Platform team is now taking it a step further and will be open sourcing our internally developed Myspace OpenSocial Gadget container. Now there will be a high quality and highly scalable .Net implementation of an OpenSocial Gadget container available to the community. This will provide an excellent complement to the Java and PHP based containers developed by the Shindig project as we continue to support OpenSocial as one of the foundational building blocks of the open web.

If you would like to see a preview of the template framework code, it is available for download at Project Negroni on Google Code. In the coming weeks we'll be releasing the OpenSocial gadget renderer controls as well so you can start exploring our code, testing your gadgets locally, and even implementing your own gadget container on your .Net hosted site!

OpenSocial State of the Union Summit on May 18th

Chris Cole — Wed, 28 Apr 2010 17:31:00 GMT

This has been an amazing year for OpenSocial. The spec group hammered out the full release 1.0 version of the OpenSocial specification, we cleaned up the APIs, and added a templating system. MySpace launched a major revision of the open platform with our support for the 1.0 specification as well.

All this makes it high time we had a celebration to reconnect and reflect on our achievements as a community, have some drinks, and start planning the next version of OpenSocial. To that end, you're all invited to join us for the OpenSocial State of the Union event being held on May 18th at the San Francisco MySpace offices. Registration is free and food, drinks, and t-shirts will be provided. If you're attending Google I/O the next day, this makes a great warm-up event that will give you a deep dive on what's new in Social Networking and an opportunity to talk face-to-face with the various members of the OpenSocial community and make your voice heard. Hope to see you there!

Book available: Building OpenSocial Apps

Chris Cole — Fri, 22 Jan 2010 08:09:00 GMT

At MySpace we want to provide as many resources as possible to developers to help them build great, social applications. As an augment to the resources currently available (like the MySpace developer site) I’m happy to report that a new book, "Building OpenSocial Apps," is now available. The book covers everything from "building an app" basics to advanced OAuth signing and invoking the REST APIs from an external server. It even throws in a bit about OSML and the next generation platform for building apps on MySpace. It's published as part of the Addison-Wesely Professional series of books and is available from their website, Amazon, and at fine booksellers near you. Oh yeah, I’m also one of the authors, along with Chad Russell and Jessica Whyte ;)

http://www.informit.com/store/product.aspx?isbn=0321619064

Here’s what people are saying about the book:

...You can tell the authors have spent a lot of time building applications within the OpenSocial realm because they explain all of the major pain areas and the do's and don'ts of application development in this space... If I'd had a text like this, specifically the area of how to talk to the parent container, when I was building my first application on MySpace, I would have saved myself a week-long roundtrip ...

- Jon LeBlanc, Yahoo Developer Network
http://developer.yahoo.net/blog/archives/2010/01/book_review_building_opensocial_apps.html

In case you missed the DevJam in San Francisco on Jan 14th, I'll be speaking at the Silicon Valley Web Builder group meeting on Wednesday, January 27th. Come by, say hi, and learn a bit more about the latest developments on the MySpace platform.

OpenSocial 0.9 OSML and Data Pipelining Beta Launch

Chris Cole — Fri, 04 Dec 2009 20:30:00 GMT

Today we are announcing the public beta of OpenSocial 0.9 with OSML and Data Pipelining. For off-site developers and API-based apps, we've had OpenSocial 0.9 REST APIs available for a few months, go check it out. This beta launch today represents the second half of an exciting and feature-packed release of OpenSocial on the MySpace Developer platform.

"What does OpenSocial 0.9 do for me?" you might ask. There are lots of great things:

A simple tag-based syntax for accessing data (Data Pipelining).
A powerful template system for defining reusable content as "custom tags" for server-side or client-side rendering (OSML).
A rich expression language for accessing data (OpenSocial Expression Language - or OS EL).
Improved Gadget XML support for writing cross-container apps.
Internationalization support with message bundles.
Faster renderings performance

Now, instead of writing 30+ lines of JavaScript code with requests and callback handlers to get a list of friends, one Data Pipeline tag can retrieve this data:

<os:PeopleRequest key="myFriends" userId="@viewer" groupId="@friends" />

If your app needs to display and format data and UI components, it can be done with OSML markup instead of JavaScript. To define a tag "myapp:PersonBlock" showing a person's name and image in a box, use the following markup.

Any data declared with Data Pipeline tags can be easily accessed via the OpenSocial Expression Language (OS EL) within your app. The code to show the name of the first friend in the friend list registered under the key "myFriends" is as simple as this:

The first friend's name is: ${myFriends[0].displayName}

Improved Gadget XML support means your app's source code can be managed with a single code file. Porting between other OpenSocial containers will be greatly simplified. We're also exposing REST APIs for app management. You'll be able to wire in your favorite code editing tools for app management.

As part of the improved Gadget XML support and the new OS EL, you can easily internationalize and localize your app to be used in different cultures. The text of your app can be defined in different message bundles and accessed via OS-EL statements. A "Hello World" app supporting English and Spanish would contain code as below:

<Locale> 
 <messagebundle>
  <msg name="greeting">Hello World</msg>
</messagebundle>

</Locale>

<Locale lang="es">
  <messagebundle>
  
  <msg name="greeting">Hola Mundo</msg>

</messagebundle>

</Locale>


...


${Msg.greeting}

This post is just a teaser of what's coming from the MySpace Developer Platform team. Over the next several weeks we'll be diving into the features of 0.9 in more depth, adding tutorials, and building sample apps to get you up and running.

There will be a number of tutorials on creating OSML apps linked to from the OpenSocial Version 0.9 Wiki Page. For now, you can create a friends list app as follows:

1. Go to the developer site, sign in, and create a new On-site app named "My Friends".

2. On the Upload App XML page, scroll down and click the (Beta) App Gadget Source Editor button

3. Click the Install button on the gadget editor screen to install the app you've just created.

4. Insert the below code in the source text box and save:

<?xml version="1.0" encoding="utf-8"?>
<Module xmlns:os="http://ns.opensocial.org/2008/markup" >
  <ModulePrefs title="Friends need Hello also" description="This is the desc">
    <Require feature="opensocial-0.9"/>
    <Require feature="opensocial-templates"/>
    <Require feature="opensocial-data"/>
  </ModulePrefs>
  <Content type="html" view="canvas">
    <script type="text/os-data">
     <os:ViewerRequest key='vwr' />
     <os:PeopleRequest key='friends' userId="@viewer" groupid="@friends" />
    </script>
    <script type="text/os-template">
     <h1>Hello world, ${vwr.displayName}</h1>
	 Your friends are:

	 <div>
	 <os:Repeat expression="${friends}">
	 <p>
	 Friend number ${Context.index} is: ${Cur.displayName}
	 <img src="${Cur.thumbnailUrl}" />
	 </p>	 
	 </os:Repeat>	 
	 </div>

  </script>
 </Content>
</Module>

Happy coding!

New Features for OpenSocial 0.9 REST APIs

krunal — Wed, 18 Nov 2009 00:38:00 GMT

Hi everyone,

We are extending our 0.9 REST API offerings by adding new endpoints as well as adding new features to existing endpoints to make our 0.9 offering richer. We are committed to exposing data through Open Standards so app developers can create the finest applications on the web. Some of these new features are not part of the previous MySpace REST APIs so this should encourage you to switch to 0.9 if you haven’t done so already.

The link to the main resource page for REST 0.9 APIs is located here. Please find documentation links and highlights of these new features below. Please review our Terms of use, especially Section 10.2, before you start using these features.

New Endpoints

StatusMoodComments

This endpoint provides a way to fetch the comments posted on a user’s StatusMood updates. It also provides a way to request the comment author’s basic info (image, name and profile URL) along with the comments themselves. This could reduce the number of calls to the server you need to make if you plan on displaying the commenter’s data along with the comments.

Please see details here.

ProfileComments

This provides a way to fetch the comments posted on a user’s profile. It also provides a way to request the comment author’s basic info along with the comments, which again will reduce the number of calls to the server if that information is needed.

Please see details here.

MediaItemComments
You can now fetch comments posted on a user’s images and videos. Again, this endpoint allows you to fetch the comment author’s basic info to save a second request to the server.

Please see details here.

Enhancements

StatusMood

The StatusMood endpoints now offer APIs to fetch friends’ status mood updates as well as provides a way to fetch StatusMood history.
Apps can also fetch recent comments on a user status in the same call.
MySpace now allows syncing/updating StatusMood from various sources like Twitter. You can get that information in your requests.

Check the documentation for the StatusMood APIs here.

Also don’t forget to check out the filters that this endpoint has to offer.

Activities

We are also adding Activity Streams extension properties to activities returned from our OpenSocial 0.9 Activities endpoint in this release. Activity Streams is a data format that describes what people are doing around the web, for example: posting photos and videos, sharing music with friends and writing blog entries. If you are already familiar with the Activity Streams atom format, you can now access all the Activity Streams goodness, like actors, verbs, objects and object-types, in JSON and plain old XML. Find more information about Activity Streams on the http://activitystrea.ms web site.

Check out the MySpace implementation for the same here.

SDKs

Our PHP and Java SDKs have been updated to support these new features and the others are in the works. Also, these new features are developed using Open Standards like OpenID, OAuth and OpenSocial which should help make your experience smooth.

Also, if you have missed out, visit this earlier blog post for more information about complete suite of REST 0.9 APIs.

Happy coding!

App Notifications Beta Release

my␣ CodeStorm — Mon, 20 Apr 2009 23:10:00 GMT

Developers can now generate custom notifications from their applications.

App Notifications are generic one to one communications from an application to a specific User of that application. In addition to providing a framework for communicating general application state messages, App Notifications also include the ability to allow the User to execute an application specific action from multiple choices.

The following documentation is for a BETA release. At this time:

App Notifications can only be received by Developers of the application.
App Notifications will expire after 7 days.
Users will only see the 5 most recent notifications per app.

Please read the App Notifications documentation for more information.

Posted by: Bryan Green
a.k.a. Codestorm

MySpaceID and the Importance of Building on an Open Stack for the Social Web

8BitKid — Tue, 07 Apr 2009 20:23:00 GMT

At MySpace, we recently released several critical new feature enhancements to MySpaceID, a product under the MySpace Open Platform. We delivered OpenID support, an OpenID/OAuth Hybrid experience, and support for syndicating “Friend Updates” via the emerging Activity Streams specification.

These new components to the MySpace Open Platform allow us to not only provide developers with new tools to create distributed applications that are built on top of our social platform, but also to deliver an identity solution that builds on top of the “Open Stack” to provide flexible an extensible options that embrace open standards.

OpenID aligned perfectly with MySpaceID as an authentication technology. As a social portal, we already embraced the notion of representing identity with a URL. An overwhelming number of our users have setup vanity URLs (i.e. myspace.com/pixelelated) and so we knew that OpenID would align well with our users. In addition, we wanted to make sure that we were working with the flow of the web, and we strongly believe that collaborating on open standards is critical to this mission.

As we worked on our OpenID solution for MySpaceID, we knew that we had to rollout the technology in a way that emphasized a lightweight and simple interface design and user experience. OpenID has wrongly been maligned by a stigma that the technology can’t be easy to use. Our aim was to break that label and demonstrate with our MySpaceID product that OpenID and usability aren’t conflicting terms. Luckily, there was a community ready and willing to help. The progress made at two OpenID Usability Summits helped us refine our implementation and allowed us to leverage the collective knowledge of other OP’s. This is the strength of open standards: the ability to work together to forge ahead and work together to solve a problem.

When working on the MySpaceID design, we embraced a pop-up window for login to help make the user experience even easier, and to help the integrating relying party offer a clean hand-off. We support both directed identity as well as standard URL-based discovery, and ultimately feel that by offering modular options to developers we are creating the most value for our users. In addition, by rolling out the OAuth Hybrid extension with this, we can allow our users to provision web service access to their MySpace profile, friends, content, and activities in the same step.

Beyond our new enhancements around single-sign on with OpenID, and the rollout of the Hybrid protocol, we are supporting the new Activity Streams specification. A core part of the DNA of MySpaceID is empowering the user to take their data with them. By offering API’s for sharing activities, we’re enabling our users to take their own activities and share them through aggregation and lifestreaming services. In addition, developers can provide a user with a window into their life on MySpace by incorporating the API in Dashboard-style widgets, such as our implementation with the new Yahoo! homepage. With activity sharing, we wanted to go beyond just offering the functionality and ensure that we were working with the community to implement something that could be standardized. We embraced this philosophy when collaborating on the Portable Contacts spec and worked to align it with OpenSocial, and so we were quite comfortable with this model of development.

I hope that we have shown that our choice for the technological piping which powers MySpaceID (OpenID, OAuth, Portable Contacts, OpenSocial, and Activity Streams) didn’t negatively impact the experience we could provide. In fact, it was quite the opposite. Our choice to embrace these open standards has given us a more powerful and flexible platform. We’re excited to prove that a MySpace user can visit any site that has integrated MySpaceID and go from a button click to bringing their identity with them, all while doing it in a way that has a clean user experience and puts the user in control of their privacy, security, and data. As an OpenID community, we’ve all worked to make tremendous progress over the past year, and I think we’re only beginning to realize the real potential to empower users through open standards for the social web.

Content Rewriting in OpenSocial 0.9

Scott — Thu, 29 Jan 2009 20:00:00 GMT

Content rewriting is a new feature defined for OpenSocial 0.9. It allows a container to optimize some aspects of an application for use within that container. Before I explain what the feature does, we need to take a look at how OpenSocial applications and containers can handle resources. Besides gadget markup, OpenSocial applications reference other files such as:

Cascading Style Sheets (CSS)
JavaScript (JS)
Images

To help improve the load time of all applications, reduce the number of requests for resources, or to move resources closer to consumers, a container will want to rewrite application content. For CSS and JS files, the container will minify and cache the file on the container servers. As an application becomes more popular, people at all different locations around the globe might be using that application. The overall user experience can be improved by copying JS, CSS, and image files to the MySpace content distribution network (CDN) and then updating the gadget markup to point to the new file locations.

As an application developer, you might appreciate this kind of help but will want to control which resources a site like MySpace can cache and which resources must be retrieved from your own servers. Maybe you update a file frequently, customize it based on some parameters, or have some other reason that you want to serve up the file. One thing you do not want is to see a container unilaterally decide to rewrite everything.

Using these ideas as a framework, the content rewriting feature was added to OpenSocial. This feature is exposed as a gadget feature and has the following general form:

<Param name="exclude-url">moreexcluded</Param>

</Optional>

The parameters all handle different aspects of rewriting.

expires: Indicates how many seconds to use as the minimum HTTP cache time for content. The value actually used will be the smaller of expires and the cache control headers present in the fetched content. If the application server indicates that an item should only be cached for one hour and expires states three hours, the item will be cached for one hour. By default, expires is set to one day (86400 seconds). This parameter can only appear once.
include-url: Indicate which URLs to include in rewriting. To rewrite all GIF references, use <Param name="include-url">.gif</Param>. The string "*" is special and implies all URLs. When not specified, a container uses a default value of "*". This value may appear multiple times, once per resource. Values here are not case sensitive, meaning that MyAPP.js and myapp.js are equivalent. Regular expressions and globbing (ex: foo*.css) are not supported.
exclude-url: Indicates which URLs to exclude in rewriting. Otherwise, this follows the same rules as include-url.
minify-css: Controls whether the container will attempt to minify css is style tags and referenced css files. This may be set to true or false. By default, the value is true.
minify-js: Controls whether the container will attempt to minify JS in script tags and referenced JS files. This may be set to true or false. By default, the value is true.
minify-html: Controls whether the container will attempt to minify HTML content. This may be set to true or false. By default, the value is true.

With all of the minify-* settings, you can exclude/include specific files as needed. Besides all of this, a container may also do the following:

Extract @import directives from style tags and convert them into link tags in the head tag of the containing HTML content.
Merge multiple CSS fetches from successive link tags into one link tag that causes the proxy to concatenate the content fetched from the individual URLs.
Merge contiguous <script src=xxx> tags into one concatenating proxy fetch.

The really interesting thing about this particular feature is that you should not need to write your code to worry about whether or not the feature is present in a given container. Go ahead and start using this one now by adding it as an optional feature in your gadget XML. When a container implements the feature, your application will just start seeing the benefit. All you should see is a lighter load on your server for images, CSS, and other resources.

What's New in MySpace OpenSocial 0.8

Chad Russell — Thu, 08 Jan 2009 21:09:00 GMT

The spec for OpenSocial 0.8 has been finalized and MySpace’s implementation has been released. There are some key benefits that 0.8 adds over 0.7 on the MySpace platform. The JavaScript container more closely conforms to the spec and some MySpace specific extensions have been pulled into the OpenSocial namespace. The result of this is that your 0.8 app will port much more easily to other platforms than your 0.7 app did. The app data API has been cleaned up and made more useful.

There are also important new features and capabilities on the MySpace platform that are only available to 0.8 apps:

Open Canvas allows your app to be functional for users even before they have added the app. Learn more about Open Canvas
Custom App Activities allow 0.8 apps to post activities into user Friend Updates. Learn more about Custom App Activities
App Notifications will allow apps to message their users directly, and will only be available on 0.8

In this three part series of articles, I’ll walk you through the process of creating an application from start to finish with emphasis on the six major improvements that distinguish 0.8 from 0.7 on MySpace:

Enhancements to the opensocial.Person object
Our new permission model, dubbed Open Canvas, that makes extensive use of opensocial.hasPermission and opensocial.requestPermission
Updates to app data to accept only valid JSON
The deprecation of PostTo in favor of opensocial.requestShareApp and opensocial.requsetSendMessage
Activities
App Notifications

Read What's New in MySpace OpenSocial 0.8:

OpenSocial 0.9 Albums API

Scott — Wed, 07 Jan 2009 16:00:00 GMT

One feature we added in OpenSocial 0.9 is Albums. Albums include MediaItems: photos, movies, and songs. Several of the containers out there, including MySpace, already had different views of what an album is. For example, on our platform you can access an album today via the REST URI (/v1/users/[user id]/albums/[album id]) (docs here). The big benefit of OpenSocial is that the group standardizes how all this works so that an application written for MySpace using only OpenSocial APIs should work for Orkut, Hi5, Yahoo!, or any other container. Album support was introduced in a few different areas:

Support to the OpenSocial JavaScript library.
Support to the RESTful API
Support in the OpenSocial RPC library (an optional part of the spec not supported by MySpace at this time)

Let's take a look at the required parts of the albums support.

JavaScript changes

First, we added a bunch of new methods to fetch, add, update, and remove Albums and MediaItems. First, the methods that allow one to fetch information:

opensocial.newFetchAlbumsRequest(idSpec, opt_params): Creates an object for DataRequest to request albums. opt_params can specify the following:
o opensocial.Album.Field.ID - an array of album Ids to fetch (fetch all albums if empty, subject to pagination)
o opensocial.Album.Field.MEDIA_TYPE - an array of MediaItem.TYPE values to specify the kind of Albums to fetch.
opensocial.newFetchMediaItemsRequest(idSpec, albumId, opt_params): Fetches the list of media items in an Album. opt_params can specify the following:
o opensocial.MediaItem.ID - an array of media item ids to selectively fetch (fetch all items if empty, subject to pagination)
o opensocial.MediaItem.MEDIA_TYPE - an array of MediaItem.TYPE values to specify the types of MediaItems to fetch

The usual Filter / FIRST / MAX technique is available through opt_params for pagination on newFetchAlbumsRequest and newFetchMediaItemsRequest.

We then added methods to create update, and delete albums and media items:

opensocial.newCreateAlbumRequest(idSpec, album): Creates a new album and returns the ID of the album created. Containers implement restrictions - like allowing a viewer to create albums for only him/herself.
opensocial.newCreateMediaItemRequest(idSpec, albumId, mediaItem): Creates a new media item in the album and returns the ID of the album created. Containers implement restrictions.
opensocial.newUpdateAlbumRequest(idSpec, albumId, fields): Updates the fields specified in the params and returns void. The following fields cannot be set: MEDIA_ITEM_COUNT, OWNER_ID, ID. Containers implement restrictions.
opensocial.newUpdateMediaItemRequest(idSpec, albumId, mediaItemId, fields):Updates the fields specified in the params and returns void. The following fields cannot be set: ID, CREATED, ALBUM_ID, FILE_SIZE, NUM_COMMENTS. Containers implement restrictions.
opensocial.newDeleteAlbumRequest(idSpec, albumId): Deletes the album specified and returns void. Containers implement restriction.
opensocial.newDeleteMediaItemRequest(idSpec, albumId, mediaItemId): Deletes the album specified and returns void. Containers implement restrictions.

Of course, the objects need values. We added an object and changed a few others. opensocial.Album makes its debut. The object has several fields:

ID - string, unique identifier for the album
THUMBNAIL_URL - string, URL to a thumbnail cover of the album
CAPTION - string, the title of the album
DESCRIPTION - string, description of the album
LOCATION - opensocial.Address, location corresponding to the album
OWNER_ID - string, ID of the owner of the album
MEDIA_TYPE - array of MediaItem.TYPE, types of MediaItems in the Album
MEDIA_ITEM_COUNT - integer, number of items in the album

opensocial.Activity.MediaItem was renamed to opensocial.MediaItem since it is no longer solely related to Activities. The MediaItem type earned a few new fields:

ID - string, id Associated with the media item
CAPTION - string describing the media item
CREATED - string, creation time associated with the media item - assigned by container in UTC
LAST_UPDATED - string, update time associated with the media item - assigned by container in UTC
THUMBNAIL_URL - string, URL to a thumbnail image of the media item
DESCRIPTION - string, description of the media item
DURATION - integer, for audio/video clips - playtime length in seconds. set to -1/not defined if unknown
LOCATION - opensocial.Address, location corresponding to the media item
LANGUAGE - string, language associated with the media item in ISO 639-3 format
ALBUM_ID - string, album to which the media item belongs
FILE_SIZE - long, number of bytes (set to -1/undefined if unknown)
START_TIME - string, for streaming/live content, time when the content is available
RATING - integer, average rating of the media item on a scale of 0-10
NUM_VOTES - integer, number of votes received for voting
NUM_COMMENTS - integer, number of comments on the photo
NUM_VIEWS - integer, number of views for the media item

RESTful API Changes

We added two new XRDS types: Albums and MediaItems. The RESTful API allows one to modify items in the container from external applications or through explicit XMLHttpRequests to the container. All responses from any request always come back wrapped by a Response object. These response objects have two different forms depending on whether or not the query returns a list or a single item. It is permissible for a single item to be returned in the list form. Example:

application/json representation:

{
   "startIndex":1,
   "itemsPerPage":10,
   "totalResults":100,
   "entry":[
      //{...first item...},

      //{...second item...},
      //...
   ]
}

or, for only one item:

{
  "startIndex" : 1
  "itemsPerPage" : 10

  "totalResults" : 100,
  "entry" : {...only item...}
}

The XML representation is

</itemsPerPage>

100

</totalResults>

<entry>...first item...</entry>

<entry>...second item...</entry>

...

</response>

Any responses coming back from the RESTful API will be wrapped as shown above. You can execute different HTTP verbs against the albums API and get different results. For example:

A GET on /albums/@me/@self with yield an array of Albums
A POST on /albums/@me/@self will create a new Album
A GET on /albums/@me/@self/albumId with return only that specific album
A PUT on /albums/@me/@self/albumId will update the album
A DELETE on /albums/@me/@self/albumId will delete the album

The returned Album will be wrapped by the response shown earlier. Getting an album, you will see something like this:

application/json representation:

{
  "id" : "44332211",
  "thumbnailUrl" : "http://pages.example.org/albums/4433221-tn.png",
  "caption" : "Example Album",
  "description" : "This is an example album, and this text is an example description",
  "location" : { "latitude": 0, "longitude": 0 },
  "ownerId" : "example.org:55443322"

}

application/xml representation:

<thumbnailUrl>http://pages.example.org/albums/4433221-tn.png</thumbnailUrl>

<caption>Example Album</caption>

<description>This is an example album, and this text is an example description</description>

</location>

<ownerId>example.org:55443322</ownerId>

</album>

Once you have an album and its ID, you will want to retrieve its contents. The contents of the albums are MediaItems. Like the Album API, a different combination of HTTP verb and URL gives different results:

A GET on /mediaitems/@me/@self/albumId with return the media items in the album
A POST on /mediaitems/@me/@self/albumId can be used to create a new media item
A GET on /mediaitems/@me/@self/albumId/mediaItemId will return the media item
A PUT on /mediaitems/@me/@self/albumId/mediaItemId will update the media item
A DELETE on /mediaitems/@me/@self/albumId/mediaItemId will delete the mediaItem

Each MediaItem will be wrapped in a response, looking something like this:

application/json representation:

{
  "id" : "11223344",
  "thumbnail_url" : "http://pages.example.org/images/11223344-tn.png",
  "mime_type" : "image/png",
  "type" : "image",
  "url" : "http://pages.example.org/images/11223344.png",
  "album_id" : "44332211"

}

application/xml representation:

<thumbnail_url>http://pages.example.org/images/11223344-tn.png</thumbnail_url>

<mimeType>image/png</mimeType>

<type>image</type>

<url>http://pages.example.org/images/11223344.png</url>

</MediaItem>

OK-- that's a lot to digest.

As always, if you want to join the discussion on OpenSocial and how it is evolving, please join the container developers (we need more application developers in this conversation!) at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

Looking Forward to OpenSocial 0.9

Scott — Wed, 17 Dec 2008 22:00:00 GMT

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.

Understanding opensocial.IdSpec

Scott — Mon, 01 Dec 2008 18:00:00 GMT

The latest iteration of OpenSocial on MySpace, OpenSocial 0.8, sets a number of places where you now need to understand this JavaScript class known as opensocial.IdSpec. Before, when you needed something like the viewer or owner from an OpenSocial 0.7 method, you would just pass a string indicating 'VIEWER' or 'OWNER' and all would be fine. However, to make the ids more informative and to allow for passing IDs that belong to people or groups, the IdSpec was created. Many methods in OpenSocial take an IdSpec as a parameter. Let’s take a simple example (simple because I happen to have the 0.7 and 0.8 version handy!). In 0.7, if I wanted to get a list of the viewer’s friends and display that list to an HTML select control, I would have the following BLOCKED SCRIPT

In that code, note that to access the list of friends, I just pass in the string 'VIEWER_FRIENDS' and everything works. For 0.8, the code needs a modest change. It needs an IdSpec. The code to create the DataRequest and FetchPeopleRequest becomes either

var dr = opensocial.newDataRequest();
var params = {};
params[opensocial.IdSpec.Field.USER_ID] = opensocial.IdSpec.PersonId.VIEWER;
params[opensocial.IdSpec.Field.GROUP_ID] = opensocial.IdSpec.GroupId.FRIENDS;
var idspec = opensocial.newIdSpec(params);
var pplReq = dr.newFetchPeopleRequest(idspec);

or, to get the friends whose network distance is 1 from the viewer (just the immediate friends), you can use:

var dr = opensocial.newDataRequest();
var params = {};
params[opensocial.IdSpec.Field.USER_ID] = opensocial.IdSpec.PersonId.VIEWER;
params[opensocial.IdSpec.Field.NETWORK_DISTANCE] = 1;
var idspec = opensocial.newIdSpec(params);
var pplReq = dr.newFetchPeopleRequest(idspec);

This is a bit more wordy, but it allows for a uniform API across the methods that accept an IdSpec. For a full explanation of the mapping from the 0.7 to the 0.8 API, please see the OpenSocial v0.8 Breaking Changes Document.

NOTABLE MUSING – OpenID, OAuth, and User Experience

Allen — Sat, 25 Oct 2008 20:53:00 GMT

I believe OpenID is turning the corner into the ‘mainstream’. More importantly, I believe the “Open Stack” is starting to blossom here at MySpace!

[Photo Credit: John McCrea]

While I’ve been intrigued with OpenID since I first saw it added to LiveJournal in 2005, I never quite knew how it would “cross-over” into the mass adoption. I was always concerned by the obvious problem I refer to as the OpenID ‘chicken-or-the-egg’ problem (a.k.a. ‘provider-or-the-consumer’). Obviously, the correct answer – strive to be both!

Let me be the first to probably say it out loud in plain English – it’s often feels easier for the businesses implementing OpenID to start by being a provider.

This is based on two things:

Companies are just evolving from the former Internet era where we had ‘My Network and your Network versus their Network’ – now we are quickly moving into the ‘Cloud’. We are seeing network walls and walled gardens begin to open
Most companies believe their brand is the strongest with the largest reach therefore it’s best to be the provider. This is perfectly ok at this stage because there will be, when it makes sense, a natural distribution of consumers, providers, and both. As OpenID becomes mainstream we will see sites use OpenID with the methods that fit their particular business needs.

OpenID and OAuth are not only evolving in code, but also in User Experience (a.k.a. ease of use). Thanks to Yahoo, Google, Plaxo, and many others (including our very own Max Engel) there was major progress on the cognitive usage patterns of using OpenID and OAuth. Yahoo hosted the OpenID/OAuth UX Summit last week at their main campus - Thank you Yahoo!

You can also watch the recap of the live blogging during the "OpenID / OAuth UX Summit"

John McCrea, the author of the live blog above, works at Plaxo, helping to pioneer “Open Stack” thru his work co-authoring the Portable Contacts specification, and co-hosts a technology show -- thesocialweb.tv.
John was also a guest journalist on TechCrunch this week.

You can read his GREAT post here

You can also watch “TheSocialWeb” TV episode about the UX Summit below

Please make sure you read the two OpenID Usability Studies from Yahoo and Google.

This week Chris Messina (also a co-host on thesocialweb.tv) was the first to notice the progress MySpace is making on our own implementation of OpenID.

As we approach the 1st Birthday of OpenSocial it’s important to reflect on all the progress and excitement I’ve seen at MySpace to make sure we provide our large platform to help not only our users, but the developer community to evolve our platform. MySpace is using it’s stable of “Open Stack” technologies including OpenSocial, OAuth, OpenID, Microformats (including XFN), XDRS, Portable Contacts to build a robust Developer Platform that extends our “social affiliation” to 3rd party sites using Data Availability.

You can see blog post David Recordon (also a co-host of thesocialweb.tv) made on September 27th, 2008 One of these isn't quite like the others... that many companies are adopting the "Open Stack". From reading's John McCrea's TechCrunch article you can also see that progress is being made between "Open Stack" participants and those building a simlary but proprietary stack.

[Image Credit: David Recordon]

The most exciting part for me is seeing several companies trying similar concepts some in agreement and some in contrast, but knowing together we are advancing the over all social web

In my personal opinion, I believe we need to work hard to make sure it continues to get easier to program the web. We have a chance to make sure there isn’t a huge switching cost in social and cloud computing. I’m constantly amazed at the level of collaboration going to advance this cause - TOGETHER!

SAVE-THE-DATE: THUR, NOV 13th, 2008 – MySpace San Francisco Office – OpenSocial - 1st Birthday Celebration

Allen — Tue, 21 Oct 2008 03:13:00 GMT

OCCASION: OpenSocial's First Birthday!
DATE: Thursday, November 13th, 2008 at the MySpace San Francisco Offices

Hard to believe, but OpenSocial is just a few weeks shy of being a full year old! To celebrate, we're getting together to look back on the great progress we've all made in the past year and to discuss where we should take OpenSocial next.

And of course, we'll eat birthday cake!!!

You're invited! The event, which is free and open to anyone, will be on Thursday, November 13th, and is being hosted in San Francisco at MySpace's SOMA office.
Developers, containers, and API designers alike have done a lot, even since the OpenSocial Summit in May, and we're excited about showcasing the cool stuff developers have done, talk about recent container launches, and discuss the future evolution of the spec.

The day will include:

- Application developers talking about their experience developing with OpenSocial Discussions and demos of the latest spec proposals (e.g. OpenSocial Templates)
- Updates from OpenSocial containers such as MySpace, Yahoo!, orkut and iGoogle
- Hacking! Yes, lots of time for programming with numerous experts on hand.
- Partying! I already mentioned birthday cake, right?

We'll provide food, drink, and the Hi-Fidelity Internets (a.k.a. Wi-Fi). Doors will open at 10 am, and we'll finish off in the evening with a proper birthday party and social hour, so bring your party hat and get ready to code.

If you have any questions, comments or suggestions for the event, please visit the OpenSocial community forum.

If you're going to be joining us, please help us plan by RSVP'ing for the event!

Posted by Allen Hurff, on behalf of the OpenSocial Foundation

Other Links: Google's OpenSocial - 1st Birthday Celebration Post