Over the weekend I got the following mail from an RSS Bandit user. The body of the message read

Have a suggestion on a set of blog entries (or articles for msdn or whatever) related to moving rss bandit to .net 2.0 / vs 2005. I’ve taken an application that uses the xpexplorerbar and imported it directly to vs 2005. I’m unable to compile due to a p/invoke issue (with LoadBitmap I believe). There is some documentation on MSDN for this, I’m sure it will be simple to correct.

In any case, RSS Bandit really is a better Windows Forms reference app than anything Microsoft is shipping with the product. It would be a very educational and worthwhile effort to document the steps required to move RSS Bandit to the new technology. As far as I’m concerned, Microsoft should champion the effort. Is there any chance this could happen?

We don't plan to move to v2.0 of the .NET Framework in the near future. RSS Bandit has a decent sized user base, with over 200,000 downloads this year. Most of these users are on v1.1 of the .NET Framework. We don't plan to move until a large number of our user base has migrated to v2.0 of the .NET Framework. Once this happens, we'll consider moving our development to .NET Framework v2.0. I assume this is about 1 to 2 years away.

I hate to promise anything so far in advance but if I have time after we port our application I will document some of the trickier issues in migrating to v2.0 of the .NET Framework. More than likely it'll just be a bunch of postsin my blog as opposed to a focused article on MSDN. I'm already so far behind when it comes to articles that I don't want to promise any more. 

Yesterday I sent out mail to a few dozen beta testers to let them know that we had started the beta of our implementation of the MetaWeblog API for MSN Spaces. For the uninitiated, the MetaWeblog API will enable you to create, update and delete posts within the blog on a space. This means that you'll be able to use tools like Blogjet and W.Bloggar to manage the blog on your space. A number of other interesting scenarios are now enabled by this as well including

• Photo sites like Flickr that have a "Post photo(s) to your weblog" feature can now integrate with MSN Spaces.

• Plugins for posting to MSN Spaces can be added to traditional text editors. An example of this is the Blogger for Word plugin

• RSS/Atom readers that have a "Blog This" feature can be used to post directly to your space.
  

There are a lot more interesting ideas one can explore once the API is widely available. If you are interested in the beta testing our implementation of the MetaWeblog API, send me email; dareo at microsoft.com.

Google has reintroduced their Google Desktop with a vengeance. It was evil enough the first time around, but this time it’s downright scary. My original complaint was that Google Desktop ignores basic practices amongst RSS readers for saving bandwidth on the sites it is polling. It was pinging my site every 5 minutes asking for updates without caching the results and thus was using an unreasonable proportion of my bandwidth.

Since a new version was recently released,  I decided to try it out to see if the issue had been fixed since I sent them mail. I installed Fiddler to monitor the traffic of the application and what I found out surprised me a great deal. Google Desktop not only pings sites every 5 minutes in a manner inconsiderate of their bandwidth but it also does so without the users direction. Below is a screenshot of some of the HTTP traffic generated by Google Desktop

The highlighted requests are requests to URLs of Atom & RSS feeds that were in my browser cache by Google Desktop. I did not configure the application to fetch these feeds. So not only does Google Desktop flood websites with feed requests in a manner bordering on the behavior of a malicious application, it also does this automatically without the end user explicitly subscribing to the feed.

That's messed up.

In the post Feeds and well-formed XML Sean Lyndersay of the IE RSS team writes

Our years of experience in with HTML in Internet Explorer have taught us the long-term pain that results from being too liberal with what you accept from others. Hence, we’ve adopted the following overriding principle for IE 7 and RSS platform in Windows Vista: 

 We will only support feeds that are well-formed XML.

This principle allows us to build a more predictable feed parser. As a platform, it's important that applications using the platform to consume feeds can rely on the fact that the platform will always be providing information in the way that the publisher intended (trying to guess what a publisher meant to do when there is an error in a feed can be tricky, at best). We also spoke to several people in the RSS and developer community at Gnomedex and at PDC, and they wholeheartedly supported this.

Hell Yeah!!!

I saw someone reference the Dave Luebbert's reasons to clone Google's API and wonder what my opinion was in response. In my post from yesterday entitled Clone the Google APIs: Kill That Noise, I gave some technical reasons why we wouldn't want to clone the Google APIs for Windows Live Search.

However, there is probably a clarification that I should have made. In certain cases, there is one thing that trumps all technical arguments against cloning an API. That is when the API has significant market share amongst developers. This is one of the reasons why even though I thought that the MetaWeblog API is a disaster, we made the call that MSN Spaces will support the MetaWeblog API. Since the MetaWeblog API is a derivative of the Blogger API, you could argue that in this case we are cloning a Google API.

To me, the difference here is the case of mindshare. The Blogger & MetaWeblog APIs are widely supported across the weblogging industry and have become de facto industry standards. I don't believe the same can be said for the Google's search API. If anything, I'd say the OpenSearch is the closest to a de facto industry standard for search APIs although [for now] it has been ignored by the big three major search players.

On a similar note, I'd probably agree that the Google Maps API is probably on its way to reaching de facto standard and Yahoo! & Microsoft should just go ahead and clone it. If I worked on the mapping API for either company, I'd probably give it six months and if adoption hadn't increased significantly would consider cloning their API.

One of the most eye opening observations I heard recently was a comment by Terry Semel, CEO of Yahoo!, where he pointed out that only 5% of page views on the Web are from search yet the account for about 40% of the revenue generated on the Web. To make this even clearer, consider this recent post on Om Malik's blog entitled Bigger Than Google, MySpace is different which states

Like all community sites that rely mostly on their users to author content, MySpace has had a very difficult time trying to secure high advertising rates. Historically, advertisers have held little trust in content that is not tightly controlled editorially and, therefore, the value they are willing to attach for ads placed next to such uncontrollable content has been very low. The result is clear… MySpace ranks higher than Google in terms of pageviews, but Google will gross $6 billion in revenues this year, while MySpace will generate about $30 million. The delta, which can be measured in orders of magnitude, is almost unbelievable. I realize the comparison is not directly apples to apples, but even so!

I bring this up because this is where Murdoch’s strategic opportunity lies… in eliminating that gap. Put another way, MySpace has a multi-billion dollar opportunity to exploit, which promises to break News Corp out of the media stock depression that it and all its fellow conglomerates have been suffering. Success on this front will demonstrate that News Corp can tap into the fastest growing segment of the advertising industry in a manner that befits Google and Yahoo!

This disparity in ad revenue is quite stunning. I agree with Terry Semel and others that this represents a significant opportunity. I wonder who'll sieze it first...

For the past few years my browser home page has alternated between http://news.google.com and http://my.yahoo.com. I like Google News for the variety of news they provide but end up gravitating back to Yahoo! News because I like having my stock quotes, weather reports and favorite news all in a single dashboard.

This morning I decided to try out live.com. After laying out my page, I went to microsoftgadgets.com to see what gadgets I could use to 'pimp my home page' and I found a beauty; the Seattle Bridge Traffic Gadget . I've talked about the power of gadgets in the past but this brought home to me how powerful it is to allow people to extend their personalized portal in whatever ways they wish. Below is a screenshot of my home page.

I'm definitely toying with building my own gadgets now. Matt has a killer gadget he's been working on in his free time that I think will be much appreciated by live.com users. If I ever find some free time, I suspect the gadget I'll end up writing will be one that has to do movie listings. Perhaps a gadget that shows the box office rankings of the previous week and also upcoming listings with information on local showtimes. Or maybe an MSN Spaces photo album gadget in the same vein as the Flickr gadget. There are not enough hours in the day...

From the press release Microsoft Acquires FolderShare, a File-Synchronization Technology Provider we learn

REDMOND, Wash. — Nov. 3, 2005 — Microsoft Corp. today announced it has acquired FolderShare™, a leading service in the emerging space of file synchronization and remote access technology that helps customers access information across multiple devices. FolderShare customers will continue to be able to enjoy the service at http://www.foldershare.com. Financial details of the acquisition were not disclosed.

Launched in 2002 and owned and operated by Austin, Texas-based ByteTaxi Inc., the award-winning FolderShare service saves customers the hassle of sending large files via e-mail, burning them to CDs or DVDs and mailing them, or uploading them to a Web site. Instead, it allows customers to sync important information, making it well suited for personal or small-business use. The FolderShare service also enables private, remote access to customers’ own files from any Web browser.

"Our mission for Windows Live™ is to enable customers to easily find the information, pursue the interests and deepen the relationships that enrich their lives," said Blake Irving, corporate vice president of the MSN Communication Services and Member Platform group at Microsoft. "I'm thrilled with the acquisition of FolderShare and the opportunity to offer this technology with Windows Live software and services. FolderShare technology will help customers access their information anytime, anywhere and on multiple devices, unifying their overall experience."

FolderShare is an awesome product so this is definitely good news. Even better is that they are joining our group (the Communication Services Platform). Windows Live is looking better and better every day.

Yesterday Dave Winer wrote in a post about cloning the Google API Dave Winer wrote

Let's make the Google API an open standard. Back in 2002, Google took a bold first step to enable open architecture search engines, by creating an API that allowed developers to build applications on top of their search engine. However, there were severe limits on the capacity of these applications. So we got a good demo of what might be, now three years later, it's time for the real thing.

If you didn't get a chance to hear yesterday's podcast, it recommends that Microsoft clone the Google API for search, without the keys, and without the limits. When a developer's application generates a lot of traffic, buy him a plane ticket and dinner, and ask how you both can make some money off their excellent booming application of search. This is something Google can't do, because search is their cash cow. That's why Microsoft should do it. And so should Yahoo. Also, there's no doubt Google will be competing with Apple soon, so they should be also thinking about ways to devalue Google's advantage.

This doesn't seem like a great idea to me for a wide variety of reasons but first, let's start with a history lesson before I tackle this specific issue

A Trip Down Memory Lane
This history lesson used to be is in a post entitled The Tragedy of the API by Evan Williams but seems to be gone now. Anyway, back in the early days of  blogging the folks at Pyra [which eventually got bought by Google] created the Blogger API  for their service. Since Blogspot/Blogger was a popular service, a the number of applications that used the API quickly grew. At this point Dave Winer decided that since the Blogger API was so popular he should implement it in his weblogging tools but then he decided that he didn't like some aspects of it such as application keys (sound familiar?) and did without them in his version of the API. Dave Winer's version of the Blogger API became the MetaWeblog API. These APIs became de facto standards and a number of other weblogging applications implemented them.

After a while, the folks at Pyra decided that their API needed to evolve due to various flaws in its design. As Diego Doval put it in his post a review of blogging APIs, The Blogger API is a joke, and a bad one at that. This lead to the creation of the Blogger API 2.0. At this point a heated debate erupted online where Dave Winer berated the Blogger folks for deviating from an industry standard. The irony of flaming a company for coming up with a v2 of their own API seemed to be lost on many of the people who participated in the debate. Eventually the Blogger API 2.0 went nowhere. 

Today the blogging API world is a few de facto standards based on a hacky API created by a startup a few years ago, a number of site specific APIs (LiveJournal API, MovableType API, etc) and a number of inconsistently implemented versions of the Atom API.

On Cloning the Google Search API
To me the most salient point in the hijacking of the Blogger API from Pyra is that it didn't change the popularity of their service or even make Radio Userland (Dave Winer's product) catch up to them in popularity. This is important to note since this is Dave Winer's key argument for Microsoft cloning the Google API. 

Off the top of my head, here are my top three technical reasons for Microsoft to ignore the calls to clone the Google Search APIs

1. Difference in Feature Set:  The features exposed by the API do not run the entire gamut of features that other search engines may want to expose. Thus even if you implement something that looks a lot like the Google API, you'd have to extend it to add the functionality that it doesn't provide. For example, compare the features provided by the Google API to the features provided by the Yahoo! search API. I can count about half a dozen features in the Yahoo! API that aren't in the Google API.

2. Difference in Technology Choice: The Google API uses SOAP. This to me is a phenomenally bad technical decision because it raises the bar to performing a basic operation (data retrieval) by using a complex technology.  I much prefer Yahoo!'s approach of providing a RESTful API and MSN Windows Live Search's approach of providing RSS search feeds and a SOAP API for the folks who need such overkill.
   

3. Unreasonable Demands: A number of Dave Winer's demands seem contradictory. He asks companies to not require application keys but then advises them to contact application developers who've built high traffic applications about revenue sharing. Exactly how are these applications to be identified without some sort of application ID?  As for removing the limits on the services? I guess Dave is ignoring the fact that providing services costs money, which I seem to remember is why he sold weblogs.com to Verisign for a few million dollars. I do agree that some of the limits on existing search APIs aren't terribly useful. The Google API limit of 1000 queries a day seems to guarantee that you won't be able to power a popular application with the service.
   

4. Lack of Innovation: Copying Google sucks.
   

The stuff I've been working on over the past couple of months is so close to shipping I can taste it. For now you'll have to whet your appetites with the information on the list of upcoming Windows Live Offerings which include

Explore and Find New Interests

Windows Live will deliver new ways for customers to discover and explore:

Social Networking. Social Networking features for Windows Live will be based on the people whom customers know rather than strangers who may visit their blog or Web site. Social Networking in Windows Live will be centered on a customer’s unified contact list, enabling the user to find and connect with people who have similar interests, but may be new to his or her social circle. Customers will be able to choose and control who has access to discover and connect with them.

Windows Live Spaces. Microsoft will continue to invest in services that help people express themselves, and find, connect and nurture deeper relationships with others around the world. MSN Spaces will transition to Windows Live Spaces as Microsoft adds new features to the service next year.

We have a bunch of great stuff coming up over the next year or so. Thanks to Mike for spotting this list. He and I worked closely on the design of Social Networking for Windows Live and it's a feature I know lots of our users will love.