Showing posts with label data portability. Show all posts
Showing posts with label data portability. Show all posts

Sunday, June 1, 2008

Google Friend Connect vs MySpace Data Availability vs Facebook Connect

More and more users are not spending time on one website anymore. And users are getting "tired" of entering their contacts ("social network") every time again and again. The big social websites are realizing that and have created their own solutions to that. Well, potentially not their own solutions, but more their own branded solutions for what's defined by the Dataportability group.

The three announcements were:

Google's FriendConnect. It should give users a shortcut to social connections they have built on different social networks. The user can login with their Facebook, Plaxo etc accounts, allow the FriendConnect enabled site to retrieve the friends on that site, and if they're online, the user can interact with them. FriendConnect will use open standards like OpenID and oAuth. Biggest disadvantage is that an iFrame will be provided as the solution, so no API will be made available. Note that this makes Google the big switch between all these social networks! Since they don't really have a (big) social network site, this is their way of getting a piece of the cake: sitting right between all the social network sites! Some other concerns can be found here.
MySpace Data Availability. A bunch of launch partners will be able to access MySpace user data and be able to present it outside the regular MySpace widgets. MySpace users should be able to revoke the rights of the third party anytime. The third party is not allowed to store the retrieved user data. The good thing here also is that it will be made available via a REST API.


Facebook Connect. In short, the new API will give third parties' users the ability to transport the relationships from their Facebook accounts to the third parties' website. Compare it with what's now already available for Facebook applications (running on the Facebook platform) being made available for third parties. Immediately a big "chick fight" broke out, because apperently Google's Friend Connect is not respecting Facebook's user privacy control, as Facebook blocked FriendConnect! But it might just be Facebook protecting it's own turf :-)


Relationship with Dataportability.org
"The DataPortability Workgroup is actively working to create the ‘DataPortability Reference Design’ to document the best practices for integrating existing open standards and protocols for maximum interoperability (and here’s the key area) to allow users to access their friends and media across all the applications, social networking sites and widgets that implement the design into their systems."
So, let's hope the above initiatives will comply with the standards defined by the DataPortability Workgroup.


Relationship with OpenSocial
Both Google and MySpace are in the OpenSocial Foundation ("a common API for social applications across multiple websites. Built from standard JavaScript and HTML"). For MySpace their Data Availability project is outside the OpenSocial framework, but will stay involved in it too and incorporate when available.


The current status
All three are announcements are kind of the "branded" version of DataPortability implementations within the respective organisation. The furthest seems to be MySpace:
Facebook: no technical specifications released
MySpace: rolling out with only a few launch-partners
Google: not ready to launch yet.

Sunday, January 13, 2008

Best of this Week Summary 07 January - 13 January 2008

  • The DataPortability.org is a quite recently started organisation that is trying to define the end-to-end data portability of identity, making use of existing technologies (like RSS, OpenID etc) as much as possible. Biggies that joined this organisation already are for example Google, Facebook and Plaxo.

  • Great article on the motivations and issues on the apparent move to the new web development platforms and architectures like PHP, Ruby, RoR, REST and WOA. Also includes a simple example how you can really quickly create a RoR application and use its auto-generated REST API.

  • Nice story/blog of a (Ror) webapp Pulse (it is a web-based cash flow management tool that allows you to easily monitor the heartbeat of your small business -- your cash) that was built in one month. Includes tools used etc. They used Basecamp to communicate and collaborate between teammembers during the project.

  • Here's a good bunch of Javascript optimalisation tips for IE from Cyra Richardson, Senior Program Manager Lead on the IE team.

  • Impressive stats on the data Google processes using MapReduce technologies for their indexing and searching.

  • Short piece on how The Burton Group sees REST might be replacing SOA. Interesting is the example that explains how REST requires a different way of thinking (though I don't agree you should completely let the OO mindset go):
    Quote: "A REST application to turn on and off the lights in your building will require you to design a URI for every light bulb and then you send it on/off messages," [...] "It's not like I have a single service that manages all my light bulbs. It's a very different approach to designing a system. And it's going to be really hard for developers to get their hands around it."