Mitch Radcliffe has a blog post on ZDNet entitled Google: Does it have to be all FUD all the time? where he writes

Fear, uncertainty and doubt (FUD–see Wikipedia) is how IBM tried to retain its dominance, what Microsoft used to cement its monopoly and, now, I suggest we review recent Google news and wonder:
...
Basically, four of the last five press releases from Google have amounted to “me and my friends are going to…” beat a major competitor or rule a marketplace based on pre-announcements without a great deal of substance or products that can be seen and used today. Google sounds more like Microsoft circa 1988-to-1992, when it was launching consortia right and left to block competitors without delivering much, or any, real product. Microsoft still does this, but it doesn’t enjoy the credibility (or, better, the credulousness) that greet Google announcements.

It seems I'm not the only one that noticed this trend. I guess the Features Not Products initiative morphed into a "FUD Not Products" initiative somewhere along the line. :)

Or maybe they just hit a critical mass of ex-Microsoft employees from the old days.

PS: For bonus points, read Dave Winer's Why Google launched OpenSocial.


 

There's been a bunch of activity in the Windows Live world this week. The first bit of news is that a service I've been wanting us to ship for a while is now in public beta, Windows Live Calendar. You can learn more about it in the blog post titled Make some plans with the new Windows Live Calendar beta! on the Windows Live Hotmail team's blog which states

In the past few years, we’ve been investing heavily in building the best web e-mail offering. But part of the team has also been intently focused on delivering the next-generation web calendar: Windows Live Calendar. It’s been a long time coming and we’ve been pretty hush-hush about it. Today, we’re finally ready to invite the world to try the new Windows Live Calendar beta!
...

Stay coordinated with friends and family

If you have a family, you know how difficult it is to coordinate schedules between spouses and kids’ activities. If you’re a student, you know how consuming it is to find time to meet for school projects with your classmates. By sharing schedules on Windows Live Calendar, we take the chore out of coordination.

· Share as much or as little of your calendar with free/busy, read-only, or read/write permissions.

· Send friends a view-only secret link to your calendar so they don’t need to sign in with a Windows Live ID.

You can also make your calendar public, so if you’re running a business or an organization that is keen on promoting events, you can make it easy for people to find out what’s going on.

Get reminded

Sometimes we forget our commitments so Windows Live Calendar delivers you reminders through e-mail, Windows Live Messenger, or an SMS message on your mobile phone. You can also wake up to your upcoming schedule by including an RSS feed of your calendar on your favorite home page like Live.com, or My.MSN.com. Because Windows Live Calendar supports the iCal standard, you can add any ICS-based calendar you find on the Internet so you don’t miss out on your favorite sports games, movie openings or upcoming holidays. To start, try our holiday calendar list or go to the iCalShare site.

I've been using it quite a bit already and I have to say there's all sorts of AJAXy goodness in the product which is also described in the blog post. The bit in red font above is something I started of working with the Calendar team on until I switched projects and Ali took it over. Congratulations to the Calendar folks. I know they've been wanting to get this out for a while. Kudos on a great beta.

The next bit of Windows Live news is that you can now get a @live.com email address by going to http://get.live.com/getlive/overview or http://www.windowslive.com/freshstart.html . The latter page informs readers

Here's the deal—if you currently have an e-mail address with Hotmail.com or MSN.com or a Microsoft Passport, you already have a Windows Live™ ID. Now you have a choice:

Keep your old account and continue to enjoy all of your favorite Windows Live services.

OR

Get a new Windows Live ID (i.e., example@live.com) and take advantage of your fresh start!

The page goes on to explain how to switch email addresses but still keep all your information and contacts in Windows Live Hotmail and Windows Live Messenger. The always up to date folks at LiveSide have a comprehensive list of all the @live.xx domains that are available to choose from. So what are you waiting for? Get yours, I already got mine.

The final bit of news is that the next generation of Windows Live services and desktop products is finally here. All the Windows Live desktop applications and non-beta Web properties have been refreshed. You can learn more at http://www.windowslive.com or from the press release Microsoft’s Windows Live Free Online Services Available Now.

I personally like some of the favorable press this release has garnered in press such as Mary J Foley's article Microsoft’s Windows Live finally starting to come into its own which is excerpted below

Until recently, Microsoft has floundered badly when trying to explain exactly what Windows Live is and how Live services and Live software complement Windows. Last year, the Windows Live team was unveiling new services at a breakneck pace, but doing nothing to put them in context or explain when/how Microsoft planned to take them final.

Now Microsoft is starting to talk about different groupings of Windows Live services and software. It is positioning the Windows Live Client Suite as what users should install on their home PCs. Home.live.com is the starting point for users who want to “anywhere access” to their Windows Live services. Mobile.Live.com is the home for Microsoft’s growing family of Live services for mobile phones and PDAs. For those with smartphones, another option is a client-style suite of Live services for mobile devices (like what Nokia is providing now on certain Windows Mobile phone models).

In the new Windows Live world order, the Windows Live taxonomy looks something like this:

Windows Live Client Suite (single installer and updater; client-based software with a services extension)

...
Windows Live Web Suite (service only)
...
Microsoft still has quite a way to go to make its Windows Live story truly intuitive and understandable by non-Microsoft-watchers. But compared to where the company was even a year ago, the Live team has come a long way.

Nice. That's a pretty big compliment coming from a skeptic like Mary J. :)

With all the releases, it's now time for my favorite part. Figuring out what we're going to ship next. Stay tuned.


 

Categories: Windows Live

I’ve started thinking about the next release of RSS Bandit and I thought it would be a good time to share some of my thoughts with our users and see what people would like us to add, fix or otherwise improve the application. It’s hard to believe that I started working on RSS Bandit almost five years ago. In that time, we’ve had the application downloaded over a million times and at the height of it’s popularity we were seeing up to a 100,000 downloads a month when we shipped a new release. Since then the popularity of the application has waned a little with the advent of Web-based feed readers like Bloglines and Google Reader as well as the fact that the amount of work Torsten and I can get done in our spare time pales in comparison to what folks who do this for a living like Nick Bradbury can get done.

That said, there are features I want from a feed reader that I don’t get from FeedDemon or Google Reader which is why I still work on RSS Bandit and why I started this blog entry. Below are the list of features I want us to do in the Phoenix release in order of which ones are most likely to be in the final version. Let me know what you think of them.

  • Meme Tracking: I’m now officially at the point where I don’t have enough time to read all the feeds I have in my subscription list anymore. For the most part, I’ve gotten around this by browsing programming.reddit, Techmeme and Sam Ruby’s MeMeme about once or twice a day. Although they are all great, the problem I have is that there are parts of the blogosphere that none of these sites is good at tracking. For example, none of these sites is really on top of the Microsoft employee blogosphere which I’m interested in for obvious reasons.

    I've been talking about building a feature similar to FeedDemon's popular topics for a long time but I've now gotten to the point where I don't think I can get a lot of value out of my blog subscriptions without having this feature.

  • Podcast Management User Interface: We kind of ran out of time with the last release and shipped a podcast downloading feature without an actual user interface for managing your podcasts (i.e. seeing pending downloads, percent complete, etc) which is really lame. Since I don’t subscribe to a lot of podcasts, this hasn’t been an issue. However I suspect that the reason I don’t is exactly because we didn’t complete implementation of this feature.

  • Plugin Model: One of the things I haven’t liked is that sometimes I want to add a single feature but once I check it in, I still need to wait for all the features slated for that release before we can get it out to users. We could move to having more frequent releases but I’m not sure people want to deal with reinstalling the application every two months because I added a single feature. What I’d like us to build a plugin model where we can ship meaningful extensions to the core application without having it tied to a release.

    I like the multi-pronged approach taken by Windows Live Writer where there are multiple APIs provided depending on the depth of integration and complexity of the functionality you’d like to add to the application. Torsten started on this a while ago but we never got around to refactoring the proposed extensibility APIs in a way that satisfied us.

  • Feeds Grouped by Sources: Right now, I’m not really happy with the way our integration with NewsGator Online works. There’s an issue with the fact that NewsGator doesn’t know what to do with intranet feeds or feeds that are actually on your local machine (for the wacky folks that subscribe to their system event logs). In addition, folks have asked if we'll ever integrate with the Windows RSS platform and I've had concerns about that since there are features we need that it doesn't provide.

    I’ve considered that the solution to both problems is to break out the My Feeds node into three sub-nodes; RSS Bandit feeds, Windows RSS platform feeds (shared with IE, Outlook and Windows Live Mail) and NewsGator feeds. This would require some radical re-engineering since it now assumes we’ll be using three different stacks to poll for feed updates but in the long run I think this is the right approach. This is probably the most complicated and controversial feature we’ll have in the release.  

  • A Single Node Mapping to Multiple Feeds: I was recently looking at my FriendFeed page and it brought home to me that many geeks have multiple feeds that represent the content they are placing on the Web. For example, my friend Joshua Allen has a personal weblog as well as a work-related weblog. It’s really lame to have two entries for him in RSS Bandit when it’s all the same person.

    The main problems with a feature like this aren't around the complexity of the information but more around how to represent this to users in the application in a way that is understandable and easy to manage.

If you are an RSS Bandit user I’d love to hear what you think of this list. Does this list sound relevant to you or are there more pressing features you’d like to see addressed first? Also what are your pet peeves?

PS: Someone recently asked me if there are any corporate RSS Bandit users. I know a bunch of folks use it at work and that some places actually have it as part of the default install on their work PCs but don’t have any details handy. If you have any anecdotes to share, I’d appreciate it.

Now playing: G-Unit - Poppin Them Thangs


 

Categories: RSS Bandit

November 6, 2007
@ 02:37 PM

Disclaimer: Although I work on the What’s New feed in Windows Live Spaces this should not be considered an announcement or precursor to an announcement of upcoming features of any Windows Live service.

Yesterday, I got into a debate with Yaron about whether Facebook has done enough to allow applications built on top of the Facebook platform to feel to end users as if they are part of a unified whole instead of merely being bolted on. I argued that they had, while Yaron felt otherwise.

The next time I logged into Facebook, I noticed the following which I hadn’t acknowledged up until that point. See if you can figure out the problem from the two screen shots. Mouse over for a hint.

See the Flixster Movies entry?

Where's Flixster?

The problem with building a platform on top of an existing application is that any problems users have with these platform applications ends up affecting their perception of your application in a negative way. How many people care that 70% of Windows crashes were caused by buggy device drivers that were for the most part written by hardware manufacturers and not part of Windows itself?

Recently I’ve seen a rush by some Web sites to jump on the platform bandwagon without clearly understanding how much work and how different a thought process it actually takes to get there. It will be an unfortunate shock for companies when they realize that it isn’t simply about chasing after feature sets. Building a platform is a holistic experience which includes getting the small details right, like giving users consistent opt out choices for the data they get in their news feed not just providing a bunch of APIs. Facebook is one of the few online services that gets it like 90% right and even they mess up on some things as I’ve pointed out above.

Think about that the next time someone shows you a bunch of APIs and tells you they’ve turned their Web site into a Web platform.

Now playing: G-Unit - I Wanna Get to Know You


 

Categories: Platforms | Social Software

A couple of people mentioned that my previous post on Google OpenSocial was too long and needed a five sentence elevator pitch style summary. Below is the five sentence summary of my analysis of Google OpenSocial that cuts through the hype and is just the facts.

OpenSocial is billed as a standardized widget platform for the Web, it isn't. OpenSocial is a standard set of REST APIs which social networks can utilize to expose user profiles and relationship data. Everything else required by a widget platform from authentication and authorization to user interface integration and an application directory is unspecified. OpenSocial is to a standardized widget platform as an internal combustion engine is to an airplane. A step in the right direction but still very far from the end goal.

Hope that helps. I have to go rake some leaves and run some puppy related errands so I might be slow in responding to comments over the rest of the day.


 

Disclaimer: This post does not reflect the opinions, thoughts, strategies or future intentions of my employer. These are solely my personal opinions. If you are seeking official position statements from Microsoft, please go here.

One of the Google folks working on OpenSocial sent me a message via Facebook asking what I thought about the technical details of the recent announcements. Since my day job is working on social networking platforms for Web properties at Microsoft and I'm deeply interested in RESTful protocols, this is something I definitely have some thoughts about. Below is what started off as a private message but ended up being long enough to be it's own blog post.

First Impressions

In reading the OpenSocial API documentation it seems clear that is intended to be the functional equivalent of the Facebook platform. Instead of the Facebook users and friends APIs, we get the OpenSocial People and Friends Data API. Instead of the Facebook feed API, we get the OpenSocial Activities API. Instead of the Facebook Data Store API, we get the OpenSocial Persistence Data API. Instead of FQL as a friendly alternative to the various REST APIs we get a JavaScript object model.  

In general, I personally prefer the Facebook platform to OpenSocial. This is due to three reasons

  • There is no alternative to the deep integration into the Web site's user experience that is facilitated with FBML.  
  • I prefer idiomatic XML to tunnelling data through Atom feeds in ways that [in my opinion] add unnecessary cruft.
  • The Facebook APIs encourage developers to build social and item relationship graphs within their application while the OpenSocial seems only concerned with developers stuffing data in key/value pairs.

The Javascript API

At first I assumed the OpenSocial JavaScript API would provide similar functionality to FBML given the large number of sound bites quoting Google employees stating that instead of "proprietary markup" you could use "standard JavaScript" to build OpenSocial applications. However it seems the JavaScript API is simply a wrapper on top of the various REST APIs. I'm sure there's some comment one could make questioning if REST APIs are so simple why do developers feel the need to hide them behind object models?

Given the varying features and user interface choices in social networking sites, it is unsurprising that there is no rich mechanism specified for adding entry points to the application into the container sites user interface. However it is surprising that no user interface hooks are specified at all. This is surprising given that there are some common metaphors in social networking sites (e.g. a profile page, a friends list, etc) which can be interacted with in a standard way.  It is also shocking that Google attacked Facebook's use of "proprietary markup" only to not even ship an equivalent feature.

The People and Friends Data API 

The People and Friends Data API is used to retrieve information about a user or the user's friends as an Atom feed. Each user is represented as an atom:entry which is a PersonKind (which should not be confused with an Atom person construct). It is expected that the URL structure for accessing people and friends feeds will be of the form  http://<domain>/feeds/people/<userid> and http://<domain>/feeds/people/<userid>/friends respectively.

Compare the following response to a request for a user's information using OpenSocial with the equivalent Facebook API call response.

GET http://orkut.com/feeds/people/14358878523263729569
<entry xmlns='http://www.w3.org/2005/Atom' xmlns:georss='http://www.georss.org/georss' xmlns:gd='http://schemas.google.com/g/2005'>
<id>http://sandbox.orkut.com:80/feeds/people/14358878523263729569</id>
<updated>2007-10-28T14:01:29.948-07:00</updated>
<title>Elizabeth Bennet</title>
<link rel='thumbnail' type='image/*' href='http://img1.orkut.com/images/small/1193601584/115566312.jpg'/>
<link rel='alternate' type='text/html' href='http://orkut.com/Profile.aspx?uid=17583631990196664929'/>
<link rel='self' type='application/atom+xml' href='http://sandbox.orkut.com:80/feeds/people/14358878523263729569'/>
<georss:where>
<gml:Point xmlns:gml='http://www.opengis.net/gml'>
<gml:pos>51.668674 -0.066235</gml:pos>
</gml:Point>
</georss:where>
<gd:extendedProperty name='lang' value='en-US'/>
<gd:postalAddress/>
</entry>

Below is the what the above information would look like if returned by Facebook's users.getInfo method

GET

<users_getInfo_response xmlns="http://api.facebook.com/1.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://api.facebook.com/1.0/ http://api.facebook.com/1.0/facebook.xsd" list="true">
<user>
<uid>14358878523263729569</uid>
<current_location>
<city>Palo Alto</city>
<state>CA</state>
<country>United States</country>
<zip>94303</zip>
</current_location>
<first_name>Elizabeth</first_name>
<is_app_user>1</is_app_user>
<has_added_app>1</has_added_app>
<pic>http://photos-055.facebook.com/ip007/profile3/1271/65/s8055_39735.jpg</pic>
</user>
</users_getInfo_response>

I've already mentioned that I prefer idiomatic XML to tunnelling data through Atom feeds. Comparing the readability of both examples should explain why.

The Activities Data API 

A number of social networking sites now provide a feature which enables users to see the recent activities of members of their social network in an activity stream. The Facebook news feed, Orkut's updates from your friends, and the Windows Live Spaces what's new page are all examples of this feature. The OpenSocial Activities Data API provides a mechanism for OpenSocial applications to access and update this activity stream as an Atom feed. All of the users activities or all activities from a specific application can be accessed using URIs of the form  http://<domain>/activities/feeds/activities/user/<userID> and http://<domain>/activities/feeds/activities/user/<userID>/source/<sourceID> respectively.  

Currently there is no reference documentation on this API. My assumption is that since Orkut is the only OpenSocial site that supports this feature, it is difficult to produce a spec that will work for other services without it being a verbatim description of Orkut's implementation.

There are some notes on how Orkut attempts to prevents applications from spamming a user's activity stream. For one, applications are only allowed to update the activity stream for their source directly instead of the activity stream for the user. I assume that Google applies some filter to the union of all the source specific activity streams before generating the user's activity feed to eliminate spam. Secondly, applications are monitored to see if they post too many messages to the activity stream or if they post promotional messages instead of the user's activities to the stream. All of this makes it seem difficult to see how one could specify the behavior of this API and feature set reliably for a diverse set of social networking sites.

The Persistence Data API 

The OpenSocial Persistence API allows applications to store and retrieve key<->value pairs that are either user-specific or are global to the application. An example of the former is a listing of company name and stock ticker pairs while an example of the latter is a user's stock portfolio. The feed of global key<->value pairs for an application can be accessed at a URL of the form http://<domain>/feeds/apps/<appID>/persistence/global for the entire feed and http://<domain>/feeds/apps/<appID>/persistence/global/<key> if seeking a particular key<->value pair. User-specific key<->value pairs are available at the URL of the form http://<domain>/feeds/apps/<appID>/persistence/<userID>/instance/<instanceID>.

This is probably the least interesting aspect of the API. A simple persistence API like this is useful for applications with simple storage needs that need to store user preferences or simple textual data that is needed by the application. However you aren't going to use this as the data storage platform for applications like iLike, Flixster or Scrabulous.

However I will add that an Atom feed seems like a horrible representation for a list of key<->value pairs. It's so bad that the documentation doesn't provide an example of such a feed.

Hosting OpenSocial Applications

The documentation on hosting OpenSocial applications implies that any site that can host Google gadgets can also host OpenSocial applications. In practice, it means that any site that you can place a <script> element on can point to a gadget and thus render it. Whether the application will actually work will depend on whether the hosting service has actually implemented the OpenSocial Service Provider Interface (SPI).

Unfortunately, the documentation on implementing the OpenSocial SPI is missing in action. From the Google site

To host OpenSocial apps, your website must support the SPI side of the OpenSocial APIs. Usually your SPI will connect to your own social network, so that an OpenSocial app added to your website automatically uses your site's data. However, it is possible to use data from another social network as well, should you prefer. Soon, we will provide a development kit with documentation and code to better support OpenSocial websites, along with a sample sandbox which implements the OpenSocial SPI using in-memory storage. The SPI implements:

  • Adding and removing friends
  • Adding and removing apps
  • Storing activities
  • Retrieving activity streams for self and friends
  • Storing and retrieving per-app and per-app-per-user data

The OpenSocial website development kit will include full SPI documentation. It will provide open source reference implementations for both client and server components.

I assume that the meat of the OpenSocial SPI is documentation is just more detailed rules about how to implement the REST APIs described above. The interesting bits will likely be the reference implementations of the API which will likely become the de facto standard implementations instead of encouraging dozens of buggy incompatible versions of the OpenSocial API to bloom.   

Conclusion

In general I believe that any effort to standardize the widget/gadget APIs exposed by various social networking sites and AJAX homepages (e.g. iGoogle, Netvibes, Live.com, etc) is a good thing. Niall Kennedy has an excellent series of articles on Web Widget formats and Web Widget update technologies that shows how diverse and disparate the technologies that developers have to learn and utilize when they want to build widgets for various sites. Given that Web widgets are now a known quantity, the time is ripe for some standardization.

That said, there are a number of things that give me cause to pause with regards to OpenSocial

  1. A common practice in the software industry today is to prefix "Open" to the name of your technology which automatically gives it an aura of goodness while attempting to paint competing technologies as being evil and "closed". Examples include OpenDocument, OpenID, OpenXML, OAuth, etc. In this case, OpenSocial is being positioned as an "open" alternative to the Facebook platform.  However as bloggers like Shelley Powers, Danny Ayers and Russell Beattie have pointed out, there isn't much "open" about OpenSocial. Russell Beattie asks in his post Where the hell is the Container API?

    Would people be jumping on this bandwagon so readily if it was Microsoft unilaterally coming up with an API, holding secret meetings geared towards undercutting the market leader, and then making sure that only those anointed partners get a head start on launch day by making sure a key part of the API isn't released - even in alpha. (It obviously exists already, all the partners have that spec and even sample code, I'm sure. The rest of us don't get access yet, until the GOOG says otherwise).

    Let's say we ignore that the process for creating the technology was not "open" nor have key aspects of the technology even been unveiled [which makes this more of a FUD announcement to take the wind out of Facebook's sails than an actual technology announcement], is the technology itself open? Shelley Powers points out her post Terms that

    Perhaps the world will read the terms of use of the API, and realize this is not an open API; this is a free API, owned and controlled by one company only: Google. Hopefully, the world will remember another time when Google offered a free API and then pulled it. Maybe the world will also take a deeper look and realize that the functionality is dependent on Google hosted technology, which has its own terms of service (including adding ads at the discretion of Google), and that building an OpenSocial application ties Google into your application, and Google into every social networking site that buys into the Dream.

    Google has announced a technology platform that is every bit as proprietary as Facebook's. The only difference is that they've cut deals with some companies to utilize their proprietary platform while Facebook's platform is only for use on the Facebook site. If Zuckerburg announces next week that the Facebook platform is freely implementable by any 3rd party Web site, where does that leave OpenSocial? After all, the Facebook platform is actually a proven, working system with complete documentation instead of the incomplete rush job that OpenSocial clearly is right now.

    There are all sorts of forums for proposing and discussing open Web technologies including the IETF, W3C, OASIS and even ECMA. Until all of the underlying technologies in OpenSocial have been handed over to one or more of these standards bodies, this is a case of the proprietary pot calling the proprietary kettle black.

  2. One of the things that comes along with OpenSocial is that Google has now proposed GData as the standard protocol for interacting with social graphs on the Web. This is something that I've been worried about for a while and I've written a couple of blog posts to address this topic because it is not clear that the Atom Publishing Protocol upon which GData is based works well outside it's original purpise of editing blog posts and the like. I'm not the only one that feels this way.

    Danny Ayers wrote in his post Open? Social?

    However the People Data API is cruel and unusual. It first stretches Atom until it creaks with "each entry in the People or Friends feed is a PersonKind"; then gives a further tug  (a person's name is represented using atom:title) then extends it even more (a person's email is gd:email) and finally mops up all the blood, sweat and dribble:

    Key value parameters - gd:extendedProperty - "As different social networks and other sources of People data have many different named fields, this provides a way for them to be passed on generally. Agreeing on common naming conventions is to be decided in future."

    Got to admire the attempt, but (to mix the metaphorical namespaces) silk purses don't make very good sow's ears either.

    In addition, AtomPub geek extraordinairre, Tim Bray wrote in his blog post entitled Web3S

    If you decide you totally can’t model your world as collections of entries populated with hyperlinks to express relationships, well then I guess APP’s not for you. And at the level of engineering intuition, I have to say that a monster online address book does feel different at a deep level from most online “publications” (I thought that was why we had LDAP... but I repeat myself).

    Now that we have AtomPub/GData as a de facto standard protocol for accessing various kinds of non-microcontent data on the Web as a reality, I'm done debating its suitability for the task since the horse has already left the barn. However I will continue to ask when will GData be RFC 5023 compliant?

  3. At the end of the day, the most disappointing thing about OpenSocial is that it doesn't really further the conversation about actual interoperability across social networking sites. If I use Orkut, I still need a MySpace account to interact with my friends on that site. Some people have claimed that OpenSocial will enable routing around such lock-in via applications like iLike and Flixster which have their own social networks and thus could build cross-site social networking services since they will be hosted on multiple social networking sites. However the tough part of this problem is how a hosted application knows that carnage4life@windowslivespaces is the same user as DareObasanjo@Facebook? It seems OpenSocial completely punts on satisfying this scenario even though it wouldn't be hard to add this as a requirement of the system. I guess the various applications can create their own user account systems and then do the cross-site social network bridging that way, which sucks because it will be a lot of duplicative work and will require users to create even more accounts with various services.

    Given that the big widget vendors like iLike, Slide and RockYou already have their users creating accounts on their sites that can be tied back to which social networking site the user utilizes their widgets on, this might be a moot point. Wouldn't it be mad cool if the Top Friends Facebook application could also show your top friends from MySpace or Orkut? I suspect the valuation of various widget companies will be revised upwards in the coming months.

  4. There is no mention of a user-centric application authorization model. Specifically, there is no discussion of how users grant and revoke permission to access their personal data to various OpenSocial applications. Regular readers of my blog are familiar with my mantra of putting the user in control which is why I've been so enthusiastic about OAuth. Although there is some mention of Google's Authentication for Web Application in the documentation, this seems specific to Google's implementation of OpenSocial hosting and it is unclear to me that we should expect that this is the same model that will be utilized by MySpace, Bebo, TypePad or any of the other social networking sites that have promised to implement OpenSocial. On the other hand, Facebook has a well thought out applications permission model and I would have thought it would be quite easy to simply reverse engineer that and add it to the OpenSocial spec than to simply punt on this problem.

Despite these misgivings, I think this is a step in the right direction. Web widget and social graph APIs need to be standardized across the Web.

PS: I've subscribed to the Google OpenSocial blog. So far there have only been posts by clueless marketing types but I'm sure interesting technical information that addresses some of the points above will be forthcoming.


 

November 3, 2007
@ 07:21 PM

I switched on my XBox 360 this morning only to be greeted by a green screen where the familiar XBox logo was supposed to be. In addition, it seems that I could get the sound fine but no picture. The only thing I can imagine that I did wrong was that I shut the console off while playing Marvel Ultimate Alliance instead of quiting the game before switching off the XBox 360 like I usually do.

Doing a search for "XBox 360 green screen" doesn't turn up anything particularly useful. Can anyone out there help with some suggestions on trouble shooting tips?

UPDATE: Disconnecting the XBox 360 from the power outlet for a few minutes then reconnecting it did th trick. Whew. :)


 

Categories: Video Games

In a post entitled Checkmate? MySpace, Bebo and SixApart To Join Google OpenSocial (confirmed) Mike Arrington writes

Google may have just come out of nowhere and checkmated Facebook in the social networking power struggle.

Update (12:30 PST): On a press call with Google now. This was embargoed for 5:30 pm PST but they’ve moved the time up to 12:30 PST (now). Press release will go out later this evening. My notes:

On the call, Google CEO Eric Schmidt said “we’ve been working with MySpace for more than a year in secret on this” (likely corresponding to their advertising deal announced a year ago).

MySpace says their new platform efforts will be entirely focused on OpenSocial.

The press release names Engage.com, Friendster, hi5, Hyves, imeem, LinkedIn, Ning, Oracle, orkut, Plaxo, Salesforce.com, Six Apart, Tianji, Viadeo, and XING as current OpenSocial partners.

We’re seeing a Flixster application on MySpace now through the OpenSocial APIs. Flixster says it took them less than a day to create this. I’ll add screen shots below.

Here’s the big question - Will Facebook now be forced to join OpenSocial? Google says they are talking to “everyone.” This is a major strategic decision for Facebook, and they may have little choice but to join this coalition.

Bebo has also joined OpenSocial.

I'm confused as to how Mike Arrington considers this a checkmate by Google. At the end of the day, this announcement is simply that folks like Slide and RockYou don't have to maintain multiple code bases for their widgets on various popular social networking sites. In addition, it brings the widget/gadget platform on these sites to a similar level to the Facebook platform. Of course, it won’t be on the same level unless it meets all the criteria from my post on how developers should evaluate the MySpace platform. Which is unlikely since besides MySpace, none of those sites have the userbase or engagement of Facebook users nor does any of them have the same kind of viral properties in distributing applications that Facebook platform has built-in

At the end of the day, will we see widget developers like the folks at iLike, Slide or Scrabulous leave the Facebook platform because of these announcements? Unlikely.

Will we see a mass migration from Facebook to MySpace or Orkut because you can now add Flixster or Scrabulous to your profile on these sites? Probably not.

So how is this a checkmate again?

OpenSocial simply keeps Facebook’s competitors in the game. It is more like a successful kingside castle than a checkmate.

Now playing: Backstreet Boys - Incomplete


 

In thinking about the Google OpenSocial Announcement I realized how much some of Google's recent moves remind me of Microsoft of old [for some undeclared definition of old]. We have

  • Google is now a two trick pony with two self reinforcing monopolies (Search + AdSense/Adwords) which is reminiscent of the self reinforcing nature of Microsoft's Windows + Office.

  • A scared overreaction to the growing hype of a startup that is eclipsing it in coolness. See OpenSocial reaction to Facebook

  • Several high level and very visible defections to said startup from people who were highly regarded there. Seems like just yesterday we were reading similar articles and blog posts about MSFT -> Google employee defections.

  • Said startup may be attacking Google's core monopoly in ways that were unforeseen but make sense in hindsight. See Facebook's SocialAds announcements.
  • Creation of de jure and de facto industry standards which are pitched as being great for customers but seem suspiciously like attempts at Fire & Motion. Compare WS-* to AtomPub + GData + OAuth + OpenSocial + ???.


 

James Snell has a blog post entitled Batch! which talks about the Batch processing model in GData APIs. He provides a sample of a GData batch request and points out the following

If the mere sight of this doesn’t give you shivers and shakes, let me give you a few reasons why it should:

  1. It’s not valid Atom. Note the first entry in the feed for instance. An Atom entry has an id, a title, some content, an author, some links, maybe some categories, etc. If the type of objects you want to represent does not also have those things, Atom is not the right format to use.
  2. It only works with Atom. What about binary resources like Jpeg’s? I guess we could base64 encode the binary data and stuff that into our invalid Atom entries but doing so would suck.
  3. We can’t use Etag’s and conditional requests
  4. I’m sure there are more reasons but these should be enough to convince you that a better approach is needed.

In a previous post I entitled One Protocol to Rule Them All and in the Darkness Bind Them I pointed out that since the Atom Publishing Protocol is not a good fit for interacting with data types that aren’t microcontent, it would need to be embraced and extended to satisfy those needs. In addition, this leads to problems because different vendors will embrace and extend it in different ways which fragments interoperability.

An alternative approach would be for vendors to utilize protocols that are better suited for the job instead of creating incompatible versions of a standard protocol. However the response I’ve seen from various people is that it is better if we have multiple slightly incompatible implementations of a single standard than multiple completely incompatible proprietary technologies. I’ve taken to calling this “the ODF vs. OOXML lesson”. This also explains why there was so much heat in the RSS vs. Atom debates but not so much when it came to debates over Yahoo’s podcasting extensions vs. Apple’s podcasting extensions to RSS.

Let’s say we now take it as a given that there will be multiple proprietary extensions to a standard protocol and this is preferable to the alternative, what should we have as the ground rules to ensure interoperability isn’t completely thrown out the windows? A fundamental ground rule should be that vendors should actually provide standards compliant implementations of the protocol before deciding to embrace and extend it. That way clients and services that conform to the standard can interoperate with them. In this regard, GData falls down horribly as James Snell points out.

Given that Joe Gregorio now works at Google and is a co-author of RFC 5023, I assume it is just a matter of time before Google fixes this brokenness. The only question is when?

PS: Defining support for batch operations in a standard way is going to be rather difficult primarily because of how to deal with failure modes. The fact that there is always the struggle between consistency and availability in distributed systems means that some folks will want a failure in any of the batched operations to result in the equivalent of a rollback while there are others that don’t care if one or two out of a batch of fifty operations fails. Then there are some folks in the middle for whom “it depends on the context” for which kind of failure mode they want.  

Now playing: Method Man - Say (feat. Lauryn Hill)