In recent months it has become clear to me that the largest Web companies have become quite serious about providing "web platforms"that Web developers can integrate with or build upon. Amazon (http://aws.amazon.com), Google (http://code.google.com), Yahoo (http://developer.yahoo.com) and Microsoft (http://dev.live.com) all provide online destinations where Web developers can learn how to use their Web services or integrate with their AJAX widget platforms. The problem with building a platform is that providing Web services and writing APIs is the easy part. The hard part is hard work of supporting developers who have built on your platform with proper documentation, prompt tech support, and ensuring backwards compatibility when new revisions of the platform are delivered. Today I feel like riffing on that last point; versioning and backwards compatibility.

Maintaining backwards compatibility and being mindful of forwards compatibility is one of the biggest design problems that faces platform vendors. So far, there have been numerous examples of Web companies that provide APIs failing to realize how important stability and backwards compatibility when providing a platform. I've seen numerous examples of breaking changes in APIs providing by Web companies including the Google Adwords API (shutting down old endpoints with new version), TypePad Atom feeds (switching the feed format to a new incompatible version thus breaking feed readers), del.icio.us API (changing the Web service URL and the security protocol) and Amazon Web Services (changing what is added to a shopping cart when an item is added via its Amazon specific ID) among many others. Some of these changes were necessary due to security concerns while others could have been prevented with better up front design and decision making by the platform vendor. However in all of these cases, developers that had taken a bet on the platform had to scramble to check that their applications still worked and patch/redistribute them if they didn't. That is bad. One of the primary goals of a platform vendor is to ensure that the lives of developers on their platform is as easy and smooth as possible. This means releasing a new version of the platform should not cause developers who have taken a bet on the platform to have to rewrite their code.  

In the past I've written lengthy, and fairly complex articles about versioning and XML data formats. These days, I've boiled down my guidance on Web service versioning to one phrase; Cool URIs Don't Change. This simple philosophy is actually all you need to consider when designing your RESTful Web service. You apply it in the following way

1. The Web service end point (i.e. URL) should not change. Changing the actual service end point is bad (e.g. http://del.icio.us/api/posts/get to https://api.del.icio.us/v1/posts/get) instead you should design your URI space with the knowledge that there will be multiple versions of the protocol.
   
2. The types of messages returned by the end point should not change. Thus changing the data format of the service (e.g. changing from RSS to Atom or Atom 0.3 to Atom 1.0) is a bad idea. Thus you should have a strategy for supporting multiple formats and partition your URI space accordingly.
   
3. The behavior of the end point should not change. This is the trickiest one to follow but the one that your developers will appreciate the most. New versions of the API should not change the behavior of operations previously defined at that end point. One way to reach this ideal is to partition your URI space in a versioned manner (e.g. http://www.example.com/api/v1/get-stuff in version 1 and  http://www.example.com/api/v2/get-stuff in version 2) and then never change the behavior of the old bits or at the very least keep that behavior around as long as possible.
   

That's it. That's all you really need to know about versioning and REST Web services. The rest is mainly finicky details that are primarily dependent on the specifics of the platform  and the ease with which the developers on the platform can respond to breaking changes. The harder it is for them to change, the higher the bar should be for breaking changes. For example, for Windows Live Messenger we have a high bar for breaking changes in the protocol that the server uses to talk to the desktop client because we know for a fact that not only does it take a surprisingly long time for the majority of users to switch to a new version of the client, there are users who actually cannot upgrade for a variety of reasons (e.g. new versions of desktop client doesn't work on their OS, corporate users or students who can't install software on the PC without permission, etc). On the other hand, when it comes to the internal SOAP APIs that are used to communicate between the Contacts platform and Windows Live properties such as Windows Live Spaces, Windows Live Hotmail and so on the bar for breaking changes is slightly lower because (i) they are Web applications and the (ii) set of consumers of the API is limited.

Ensuring that a Web platform has a strategy for handling backwards compatibility issues is just as important in the Web 2.0 world as it is on the desktop. Platform vendors who think otherwise are in for a rude awakening if they want adoption of their Web platform by serious developers.

It's been a while since I've written about RSS Bandit. In fact, I haven't written anything since we released v1.5.0.10 formerly codenamed Jubilee about two months ago. Between getting my work affairs in order to so I could travel to Nigeria, spending a few weeks there and then coming back to catch up on work, I haven't had much time for RSS Bandit. However I can now see the light at the end of the tunnel and will be able to start writing code again by this weekend.

Since we shipped the release, there have been two major issues reported which Torsten has been working on. In his post RSS Bandit and the 100% CPU issue the issue of the application using 100% CPU is addressed thusly 

Today I could track down an annoying issue: on some installations of the newer version of RSS Bandit (starting with the first betas of 1.5.0.x) it starts using 100%CPU time on a thread. As we started also to use lucene.NET with this new release I guessed it was a related issue, I was right. But as we run into multiple issues with lucene it was not obvious as a separate problem. So here it is:

We used a slightly modified version of lucene.NET to include the available language dependent analyzers and stopword filters. Before we released, I already fixed some obvious issues I got with e.g. french stemmer. Now we got more with the CJK (Japanese/Korean, bug report) and possibly Chinese analyzers. It looks like it get into a state it never returns. The attached debug callstack was very helpful to got the direction to search for! I found this: TextReader.Read(char[], int, int) was called and the return value checked against -1 only, not against 0 (zero). So I run over all analyzers to find all the places I have to change that code and here it is: the modified lucene.net.dll (zipped, 142K).

A number of users have grabbed the linked DLL and followed Torsten's instructions and fixed the problem. The second issue and solution can be found in the RSS Bandit forum post Beta Bugfix debugging version 1.5.0.12 where Torsten writes

All of you reporting/considering the lucene related indexing errors, please download and try the Beta Bugfix debugging version 1.5.0.12 from http://rssbandit.sourceforge.net/builds/RssBandit.1.5.0.12.CVS.bin.zip

Report any further issues related to lucene only as responses here (with the usual infos as OS and version etc.).

Thanks!

PS: you should delete the whole folder named "index" in the RSS Bandit user data folder before starting the application, the old index is possibly corrupted because of the errors before.

A number of users have reported getting exception messages related to the Lucene search index and this is due to threading issues we are facing while manipulating the search index. I thought I had handled all the issues in the final release but it seems I was mistaken. If you are an RSS Bandit user who has faced some of these issues, try out the version of the application fix linked above and let us know if the problem goes away.

Both of these fixes will be in an upcoming release of RSS Bandit that will ship at the end of the month. I may add a tiny feature with this bug fix release; adding pagination to newspaper views which is something I've wanted to do for at least a year now.

From the Microsoft press release Microsoft Launches Windows Live Hotmail Worldwide we learn

REDMOND, Wash. — May 6, 2007 — Microsoft Corp. today announced that Windows Live™ Hotmail^®, the successor to MSN^®
...
As Windows Live Hotmail begins rolling out on May 7 and continues over the coming days, consumers will be able to visit http://www.hotmail.com to sign up for a new Windows Live Hotmail account. Current MSN Hotmail customers can also update their existing account to Windows Live Hotmail by logging into their account and clicking on the green Join Windows Live Hotmail button.
...
Hotmail, is launching globally in 36 languages. The most significant upgrade for Hotmail since it pioneered the webmail industry in 1996,

• Outlook Connector. Available later this month in 11 languages worldwide, the new Microsoft Office Outlook Connector beta will enable people to view and manage their Windows Live Hotmail account from Outlook for free, with full contact, e-mail and e-mail folder synchronization.

Congrats to Omar Shahine, Reeves Little and the rest of the Hotmail crew for getting this release out the door. This has represented man-years of work from the team and lots of us across Windows Live. Also, free access to Hotmail for Outlook users has been long overdue. I'm glad we've finally given this feature to our users. Kudos all around.

You can read more about the release from Omar in his post And We've Shipped and from the Windows Live Hotmail team's blog post It's Here and the Fun Has Only Just Begun

PS: Liveside has some news about the other Windows Live mail product in their post Windows Live Hotmail launches; "Windows Live Mail" to succeed Outlook Express and Windows Mail

By now most people interested in technology news have heard the story initially reported by the New York Post in the article Bill's Hard Drive which claimed that Microsoft was planning to purchase Yahoo! and the subsequent rebuttal of this news in the Wall Street Journal's article Microsoft, Yahoo Discussed Deal. Since I work at Microsoft I'm not supposed to comment on rumors like this so I'll just point to a couple of opinions.

Charlene Li, an analyst at Forrester Research, wrote in her blog post entitled Why Microsoft + Yahoo! makes sense – and why it won’t work that

But there is one major reason why I don’t think Microsoft executives have the stomach for any sort of brand rationalization -- the continued dual branding of Windows Live and MSN. Each time I have a conversation with Microsoft about Windows Live, I get a different explanation of what it is and how it fits with MSN. If the company can’t event figure out its branding strategy with existing properties, I don’t hold out much faith that they could do so with a premium brand like Yahoo!

Robert Scoble writes in his post No “Microhoo”

I’ll tell ya one thing, though. It sure made for interesting conversation with a Yahoo employee I met tonight. We were starting to draw up where value would be built and where it’d be destroyed. There were a lot of places it would be destroyed and if two guys drinking beer can figure that out in half an hour, I’m sure that caused smarter people than us to put on the brakes. For instance one of Yahoo’s biggest properties is its email service. But that’s one of Microsoft’s biggest properties too (aka Hotmail). Then you look at finance sites. Microsoft is doing pretty well there with Microsoft Money (I met an employee who works there too and he said both Microsoft and Yahoo are way ahead of Google in finance traffic). Then you look at mapping. Again, they are pretty strong competitors there. Search? Who’s search technology would be thrown away? Advertising technology? Both Microsoft and Yahoo are pretty close there. Flickr? Clear value creation in an acquisition cause Microsoft doesn’t have anything like it. Same with Del.icio.us, Upcoming.org, Yahoo Answers, MyBlogLog. Portal? Yahoo is clear winner in brand name, but that’s just cause Microsoft has done an awful job in rebranding everything as “Live.”

As for me, two phrases popped into my head when I heard the rumor; hail mary play and post merger layoffs. I guess word association is mother...

In related news, Mike Arrington reported yesterday that Yahoo To Shut Down Yahoo Photos In Favor Of Flickr. This is a shockingly disruptive move that will definitely piss off users given how different the features and target audience of both sites are. Why would a Web savvy, user-centric company like Yahoo! do something that will so obviously cause bad blood between them and their users? How about all the employees working on Yahoo! Photos who busted their butts to make it one of the Web's most popular photo sites? The answer is simple. Yahoo! has redundant and competing products which they could no longer rationalize.

Now go back and reread Robert Scoble's post linked above then consider what a YHOO-MSFT merger would look like again.  

Have you been trying to distill the recent Microsoft Silverlight announcement into actual concrete bits and pieces? Look no further than this poster which not only lists the various supported browsers and operating systems but also highlights which class libraries from the .NET Framework will make up Silverlight

PS: Found this via Mark Pilgrim's Silly Season post. As usual, excellent and insightful writing by Mark.

Andy Conrad, who I used to work with back on the XML team, has two blog posts about Project Astoria and Project Jasper from Microsoft's Data Programmability team. Both projects are listed as data access incubation projects on MSDN. Below are the descriptions of the projects

Project Codename “Astoria”
The goal of Microsoft Codename Astoria is to enable applications to expose data as a data service that can be consumed by web clients within a corporate network and across the internet. The data service is reachable over regular HTTP requests, and standard HTTP verbs such as GET, POST, PUT and DELETE are used to perform operations against the service. The payload format for the service is controllable by the application, but all options are simple, open formats such as plan XML and JSON. Web-friendly technologies make Astoria an ideal data back-end for AJAX-style applications, and other applications that need to operate against data that is across the web.

To learn more about Project Astoria or download the CTP, visit the Project Astoria website at http://astoria.mslivelabs.com.

Project Codename “Jasper”
Project Jasper is geared towards iterative and agile development. You can start interacting with the data in your database without having to create mapping files or define classes. You can build user interfaces by naming controls according to your model without worrying about binding code. Project Jasper is also extensible, allowing you to provide your own business logic and class model. Since Project Jasper is built on top of the ADO.NET Entity Framework, it supports rich queries and complex mapping.

To learn more about Project Jasper visit the ADO.NET Blog at http://blogs.msdn.com/adonet

I was called in a few weeks ago by an architect on the Data Programmability team to give some advice about Project Astoria. The project is basically a way to create RESTful endpoints on top of a SQL Server database then retrieve the relational data as plain XML, JSON or a subset of RDF+XML using HTTP requests. The reason I was called in was to give some of my thoughts on exposing relational data as RSS/Atom feeds. My feedback was that attempting to map arbitrary relational data to RSS/Atom feeds seemed unnatural and was bordering on abuse of an XML syndication format. Although this feature was not included in the Project Astoria CTP, it seems that mapping relational data to RSS/Atom feeds is still something the team thinks is interesting based on the Project Astoria FAQ. You can find out more in the Project Astoria overview documentation.  

REST is totally sweeping Microsoft.

I've been reading a ton of blog posts containing developer reactions to Microsoft's Silverlight announcement at MIX '07. One thing that I've noticed is that people are coming to some of the same conclusions I came to in my post What Comes After AJAX?. Specifically, it is now clear that WPF/E Silverlight is a contender for the throne of king development platform for building rich internet applications (RIAs). Additionally, it is also clear that the days of Asynchronous Javascript and XMLHttpRequest (AJAX) being first choice when building rich internet applications are numbered. Below are excerpts of some of the posts I found interesting.

In his blog post entitled The Day the Web Changed: NET in the Browser! Jeff Prosise writes

MIX 07 opened yesterday and I believe we'll look back on that day as the day that the Web changed. Microsoft made several announcements, not the least of which is that Silverlight, formerly known as "WPF/E," will include a cross-platform version of the CLR that runs in the browser.

What does it mean? It means goodbye JavaScript, hello C#. It means managed code in the browser. It means an escape from HTML and browser DOMs and a better way to build browser-based UIs using XAML. It means incredibly rich browser experiences and a whole new generation of RIAs.

Soooo, ok, they released a new May CTP of ASP.NET AJAX futures. It's got some new support in there for Silverlight related stuff now. Great, awesome, love to see it and totally understand they need to pimp the new platform. What has really happened beyond that though?
...
Anyway, it seems like Silverlight is ursurping the development of the core AJAX futures and, while I'm all for Silverlight, I think it's a bad move to put these features on the backburner. They should be fleshed out and delivered. They are extremely valuable to those of us trying to build rich web browser (only) based applications.

I'd love to heard from someone inside MS on what exactly their intentions are at this point. If it's dead, fine... just let us know. If it's not, tell us what to expect and when to expect it so we can make decisions on how to proceed. I've said it before and I'll say it again, the stuff that was cut from ASP.NET AJAX 1.0 and ended up in the futures was much more important to developing rich internet applications and 1.0. It's true that 1.0 layed the groundwork, but having to cobble together all the UI in JavaScript still with $get and $addHandler, while possible, isn't what I'd call a good platform.

Drew Marsh also writes in his post Where's the MSHTML/IE news?

I find it strange that there has been absolutely no mention of what the MSHTML/IE teams are working on right now yet at Mix. I remember they stood on stage last year and talked about much shorter product cycles. Shouldn't we be expecting some kind of new enhancements by at least the early second half 2007? I really don't care about the IE shell, I care most about MSHTML coming up to speed with more/better support for CSS (gimme my selectors damn it!), enhancements to the DOM, etc.

Update: It seems I didn't provide enough context in this post because I assumed people reading this would also read my What Comes After AJAX? post. My point in this post isn't to state that Silverlight will kill AJAX. In my previous post I already mentioned that based on the data we have, Adobe's rich internet application (RIA) platform seems more likely to take the top spot than Microsoft's. Instead I was pointing out that we are further along the road towards replacing Asynchronous Javascript and XMLHttpRequest (AJAX) with a richer and more productive set of platforms. Additionally, if you read between the lines of the MIX '07 announcements, it seems AJAX is no longer the new hotness, given the lack of news on improvements to the Microsoft AJAX stack coming from the conference.

Popular consumer websites like Yahoo! Maps, Flickr, YouTube and MySpace have made rich interactivity mainstream and even expected when it comes to building a modern "Web 2.0" consumer website by using a post-AJAX platform (Flash). My thesis is that we will see more sites embracing post-AJAX platforms until we reach a tipping point where brand new Web 2.0 sites choose something like Silverlight, Flash or OpenLaszlo instead of AJAX when considering a platform for building a rich internet application. 

Yesterday I got a reminder that I've been gone from Nigeria a bit too long. I posted the following photograph and caption to my Nigeria 2007 Trip Photo Set on Flickr

One of the servants sitting down on the bed of his one room apartment.
You can see the entire apartment in this shot.

This photo and caption caused a bunch of outrage on certain Nigerian blogs leading to posts like A Presidential Servant and OBJ's Cribs as well as an angry comment on Flickr condemning me for calling the person in the picture "a servant". The person in the picture is a member of the domestic staff in my father's private home (not the presidential villa which is owned and staffed by the Nigerian government) who's responsible for serving guests, cooking and cleaning. The common term for this kind of job in Nigeria is houseboy. However since this term has been taken over by the gay community to mean something totally different (don't go to http://www.houseboy.com) I went for a non-ambiguous term that most of my readers would understand. From the answers.com definition for servant 

ser·vant (sûr'vənt)
n.

1. One who is privately employed to perform domestic services.
2. One who is publicly employed to perform services, as for a government.
3. One who expresses submission, recognizance, or debt to another: your obedient servant.

[Middle English, from Old French, from present participle of servir, to serve. See serve.]

What I forgot is that calling someone a "servant" is a derogatory term in Nigeria. I remember hearing the phrase I'm not your servant more times than I can count when growing up. So I've edited the caption and replaced "servant" with "member of my dad's domestic staff". I hope my Nigerian readers appreciate this change.

It's weird to experience culture clash when you're clashing with the culture you were raised in.

The blog post entitled Released: Contacts API, Windows Live Data Protocols on the Windows Live Dev blog states

Today we have a few more things for you, starting with this . . .

To date, access to Windows Live Contacts has been exclusively through our Contacts Control, but now we also offer an API for Contacts as well. The Windows Live Contacts API is a RESTful API that works on Address Book objects. The Contacts API offers a more granular control over the user experience than the control, and allows users to grant and revoke permission to their data on a site-by-site basis. Windows Live Data provides the protocols to manage the permissioning process.

Try them out and let us know what you think in our forum.

The Windows Live Data service provides a framework for applications to request and receive access to a user's data stored in Windows Live. An overview of the process is available in the documentation on Requesting Permission to Access Users' Windows Live Data.

The Windows Live Contacts API is a RESTful Web service created by my team for accessing a user's Hotmail contacts. How we use HTTP verbs is described in the documentation Getting Started with Windows Live Contacts API. You'll probably catch me talking about my contributions to future versions of the API in coming months.

I'm not attending MIX '07 but it looks like we're announcing some good stuff this week. because the stuff I've been working on isn't ready to be announced yet but my coworkers have dropped some cool announcements. Today we announced Silverlight Streaming by Windows Live. To understand this announcement you first have to understand what Silverlight actually is.

From http://www.silverlight.net we learn

Microsoft® Silverlight™ is a cross-browser, cross-platform plug-in for delivering the next generation of .NET based media experiences and rich interactive applications for the Web. Silverlight offers a flexible programming model that supports AJAX, VB, C#, Python, and Ruby, and integrates with existing Web applications. Silverlight supports fast, cost-effective delivery of high-quality video to all major browsers running on the Mac OS or Windows.

If that is still too complex for you; you can consider Silverlight as being akin to the Flash platform but built with the .NET platform with all the attendant benefits (i.e. development with Visual Studio and access to a ton of languages). Now we know what Silverlight is, what exactly is Silverlight Streaming by Windows Live? Glad you asked.

From the blog post entitled New! Silverlight Streaming Service on the Windows Live Dev blog we learn about http://dev.live.com/silverlight which states

Microsoft® Silverlight™ Streaming by Windows Live™ is a companion service for Silverlight that makes it easier for developers and designers to deliver and scale rich media as part of their Silverlight applications.  The service offers web designers and developers a free and convenient solution for hosting and streaming cross-platform, cross-browser media experiences and rich interactive applications that run on Windows™ and Mac..
...
Microsoft® Silverlight™ Streaming by Windows Live™ can be used either directly from the administration web site or via a REST API. The API allows you to upload, update, delete, and invoke Silverlight applications using the Silverlight Streaming service. Click here to view the complete API reference.
...
While the product is in pre-release, storage and delivery is free up to 4 GB, with outbound streaming up to DVD quality (700 Kbps). As we move out of Beta, developers/designers will have continued use of the service with up to 1 million minutes of free video streaming at 700 Kpbs per site per month. Unlimited streaming will also be available for free with advertising, or with payment of a nominal fee for the service for use without advertising.

Not only is Microsoft giving developers a platform for building Rich Internet Applications (RIA) but it is also giving developers free streaming media hosting if they plan to use the platform to build a media sharing service. This is an interesting new wrinkle in the competition between Web application platforms. The response from Microsoft's competitors will definitely be interesting. I wonder if we'll see a partnership between Adobe/Macromedia and Amazon to bundle free usage of Amazon's S3 service if you are building applications with Flex or Apollo?