One of the biggest problems that faces designers of distributed application is making sure their applications are resistant to change (i.e. versioning). Making sure services are designed with forwards and backwards compatibility in mind is especially challenging when one has no control over the various parties that will be invoking the service. 

In traditional applications, enumerated types (aka enums) are particularly problematic when it comes to versioning. The problem case being when new values are added to an enumerated type in a later version. The .NET Framework Design Guidelines about adding new values to enumerated types shows how insidious this problem actually can be. The original guidelines stated that it was OK to add values to enumerated types but this was later surrounding with lots of warnings as to why this is a bad idea. The original guideline states

It is acceptable to add values to enums

If a caller receives an enum as an out or return value (or as a parameter to a virtual method), and switches over every valid value of the enum and throws unconditionally in the default case, then added values will cause the caller to perform the default case, and throw

If a caller receives an enum as an out or return value, and performs some default behavior in the default case, then added values will behave as if they were default values

If you receive compatibility data for your application which indicates returning the new values from the existing API will cause issues for callers, consider adding a new API which returns the new (and old) values, and deprecate the old API. This will ensure your existing code remains compatible.

The following addendum was later added

Adding a value to an enum has a very real possibility of breaking a client. Before the addition of the new enum value, a client who was throwing unconditionally in the default case presumably never actually threw the exception, and the corresponding catch path is likely untested. Now that the new enum value can pop up, the client will throw and likely fold.

The biggest concern with adding values to enums, is that you don't know whether clients perform an exhaustive switch over an enum or a progressive case analysis across wider-spread code. Even with the FxCop rules above in place and even when it is assumed that client apps pass FxCop without warnings, we still would not know about code that performs things like  if (myEnum == someValue) ...  in various places.

Clients may instead perform point-wise case analyses across their code, resulting in fragility under enum versioning. It is important to provide specific guidelines to developers of enum client code detailing what they need to do to survive the addition of new elements to enums they use. Developing with the suspected future versioning of an enum in mind is the required attitude.

There is an additional wrinkle when adding values to an enumerated type in XML Web Services especially if the calling application is built using the .NET Framework. Let's say we have the following enumerated type declaration in the schema for v1 of our service

<xsd:simpleType name="SyndicationFormat">
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="RSS10"/> 
    <xsd:enumeration value="RSS20"/>     
    <xsd:enumeration value="CDF"/>

and in a later version modify it in the following way

<xsd:simpleType name="SyndicationFormat">
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="RSS10"/> 
    <xsd:enumeration value="RSS20"/>        
    <xsd:enumeration value="CDF"/>
    <xsd:enumeration value="Atom"/> 

Of course, as mentioned in the amended discussion on adding values to enumerated types in the .NET Framework design guidelines, this is a forwards incompatible change because new messages will very likely not be properly processed by old clients. However when the consuming applications are built using the XML Web services capabilities of the .NET Framework we dont even get that far. Instead you will most likely get an exception that looks like the following

Unhandled Exception: System.InvalidOperationException: There is an error in XML document (1, 1022). ---> System.InvalidOperationException: 'Atom' is not a valid value for SyndicationFormat.
   at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSyndicationService.Read4_SyndicationFormat(String s)

This is because the client code will have been generated from the v1 version of the WSDL for the service where "Atom" was not a valid value for the SyndicationFormat enumerated type. So adding a value to an enumerated type in an existing XML Web service end point is pretty much guaranteed to break client applications.

I love my day job. ;)

PS: This example is made up but the problem is real.


Categories: XML Web Services

From the Microsoft press release Microsoft Acquires Teleo, Innovative VoIP Technology Company we learn

REDMOND, Wash. — Aug. 30, 2005 — Microsoft Corp. today announced it has acquired Teleo Inc., a provider of voice over Internet protocol (VoIP) software and services that enable the placement of phone calls from PCs to traditional phones and that deliver this technology in unique ways through a variety of software and Web applications. Microsoft expects to combine the technology and expertise of Teleo with the existing VoIP investments of MSN to further develop products and services that connect consumers to the people and information that most matter to them. Financial details were not disclosed.

Founded in 2003 and headquartered in San Francisco, Teleo is a privately held company whose initial planned service offering, also called Teleo, was designed to allow customers to use their PC to make phone calls to cell phones, regular phones or other PCs. Through its integration with Microsoft® Outlook® and Microsoft Internet Explorer, the Teleo service was designed to facilitate click-to-call dialing of any telephone number that appears on-screen, for example through a Web site or via search results or e-mail.

VoIP technology already is prominently featured in MSN® Messenger as well as other Microsoft products and services. Microsoft plans to incorporate and expand upon Teleo technologies, integrating them into the infrastructure that supports MSN and ultimately projects delivering new VoIP consumer applications in future releases of MSN services.

This is pretty good news for MSN Messenger users. Instant Messaging is more than just sending text from one computer to another. Voice and video conversations are also valid ways to communicate using our instant messaging client. Also the ability to communicate with people on other devices besides their computers is also one thing we think is important. In fact, while I was in Nigeria I made heavy use of MSN Messenger's SMS to IM conversation capabilities to send messages to my girl friend's phone while she was at work back here in Seattle.

It's all about communication and the addition of the Teleo folks to our fold will only increase and improve the communication capabilities of MSN Messenger. Excellent.


Categories: MSN

Torsten just posted the following announcement about the RSS Bandit support forums

Because of the amount of spam from fake user/member accounts we changed the rules related to how new members are approved to use/post to our forums.

Each new user will be approved by one of the forum administrators manually. You will have to provide a VALID e-mail address while registering. So if you don't get approved within 10 minutes, please don't try again with other/changed e-mail addresses.
We are humans and need to sleep some minutes every day

If you get access, you will receive a mail from forumadmin at soon...

We were getting almost a dozen spam posts a day which made the forum RSS feed completely useless. We shut down accepting new members for a few days until Torsten figured out that we could add an approval process for new member requests.

Having to deal with approving new member requests is a hassle but a lot less than having to delete posts and member accounts created by spambots. Spammers suck. 


Categories: RSS Bandit

Since I've been in the process of adding support for synchronization between RSS Bandit and Newsgator Online, I've been trying to eat my own dogfood and use both applications. A ready opportunity presented itself when I travelled to Nigeria a few weeks ago and wanted to keep up with my RSS feeds. While I was in Nigeria, I was always on a dialup connection and used about four different PCs and 1 Mac. It seemed to make sense to favor a web-based RSS reader as opposed to trying to install RSS Bandit and most likely the .NET Framework on all these machines which in some cases I didn't have administrator access to anyways.

After unsuccesfully trying to use Newsgator Online I ended up settling with Bloglines instead for a number of reasons. The first being that Bloglines is a lot faster than Newsgator Online whose interface seems to move at a snail's pace over dial up. The second being that a basic feature like "Mark All Items As Read" seems to be missing from Newsgator Online. Trying to visit every feed individually to mark all its items as read became such an ordeal, I simply gave up.

I'd rather not think that I've wasted the time I've spent working on implementing synchronization between RSS Bandit and Newsgator Online since the current user experience of the latter service leaves much to be desired. I sincerely hope there are some changes in the works for the service.


Lots of folks I've talked to at work have had mixed feelings about the recently announced Google Talk. The feelings are usually relief and disapointment in equal portions. Relief because Google hasn't shipped yet another application that redraws the lines of what that class of application should look like (e.g. GMail and Google Maps) meaning we have to play catch up. Disappointment because we actually expect better from Google.

You can see some of these sentiments from various folks at MSN such as Mike Torres in his post Competition & Google Talk, Sanaz Ahari in her posts Google Talk review and Google Talk pt II, and Richard Chung in his post Google Talk Blows.

Of course, Microsoft employees aren't the only ones underwhelmed by Google Talk. Doing a quick search of the blogosphere for comments about Google Talk leads me to lots of bloggers expressing ambivalence about the application.

The most interesting reaction I noticed was from Robert X. Cringely who was inspired to ask Has Google Peaked? in his most recent column. In the article he not only asks whether Google's best products are already behind it but also points out that they have become experts at Fire and Motion. Below is the relevant excerpt from Robert X. Cringely's column

Google plays on its technical reputation even though, if you look closely, it isn't always deserved. Many Google products haven't been revved since they were introduced. And while some Google products are excellent, some aren't, too.

Google likes to play the Black Box game. What are they DOING in all those buildings with all those PhDs? I'm sure they are doing a lot that will change the world, but just as much that will never even be seen by the world. For the moment, though, it doesn't matter because Google can play the spoiler. They offered a gigabyte of e-mail storage, for example, at a time when they had perhaps one percent the number of e-mail users as a Hotmail or Yahoo. And by limiting the Gmail beta, they avoided the suffering of both those other companies when they, too, had to increase their storage allocations, but for tens of millions of real users.

Now Google will do something similar for chat and VoIP with Gtalk, pushing the others toward an interoperability that undermines the hold each company thinks it has on its users.

In my original post about Google Talk I mentioned that using Jabber/XMPP was an attempt at a disruptive move by Google. Of course, it is only disruptive if its competitors like AOL, MSN and Yahoo! react by breaking down the walls of the walled gardens they have created in their various IM products.

I find it interesting that instead of trying to push the envelope with regards to the user experience in instant messaging, Google chose to 'punk' its competitors instead. I guess we'll just have to see how MSN, Yahoo & AOL end up reacting. 


Categories: MSN

Sean Lyndersay has posted about an update to the Simple List Extensions specification. The update fixes some of the issues that were pointed out by members of the RSS community such as the problem pointed out in Phil Ringnalda's post MS Embraces RSS because RSS elements were being reused outside their original context. The cf:listinfo element now has the following structure

label="User-readable name for the sort field"
yes|no" />

User-readable name for the grouping" />


This is a lot better than the original spec* which instead of naming the element being sorted on using attributes of  the cf:sort element actually included it as a child element instead. The only problem I have with the spec is that I don't see where it states the date format that is expected to be used if the data type is date. I guess this was problematic since different syndication formats use different date formats. RSS 2.0 uses the RFC 822 format, Atom 1.0 uses the RFC 3339 format while Dublin Core [which is what RSS 1.0 dates typically are] uses the format from the W3C Note on Date and Time formats. So an extension element really can't define what the date format will be in the feed it is embedded in since it may be embedded in an RSS or Atom feed.

That is a potential gotcha for implementers of this spec. I think I'll pass at implementing support for the Simple List Extensions spec in RSS Bandit this time around since my plate is full for this release. I'll add it to the list of features that will show up in the following release [tentatively codenamed Jubilee].

* I would have linked to the spec but as usual MSDN has broken permalinks such as . Someone really needs to force everybody that works there to read Cool URIs don't change.


August 25, 2005
@ 03:28 PM

David Card of Jupiter Research has a blog post entitled Pre-emptive IM Strike from MSN where he describes one of the reasons I love working at MSN

Finally, MSN wants to remind everyone that it's got six years of experience in this stuff -- hear that, Sergey? -- and is sticking to its promise of thrice-yearly upgrades, so watch for more goodies in November.

The upgrades are all fine, but I was actually more impressed by Irving's crisp articulation of the IM Big Picture. MSN is trying to move the conversation away from IM (defined as "real-time text messaging," how dull) to "contacts." I think they downplay presence management, but that's okay, presence sounds too much like AOL-friendly talk. As does Buddy Lists, but I can't break the habit.

What's critical about IM isn't real-time text messaging but the Buddy List as a communications/presence management hub.(Link is ancient history for geek/vision cred.) You manage your buddies and buddy groups and their relationships to you (and each other), shifting those according to what persona you're inhabiting (work, home, fun, shopping, etc.) and what communications are available to you or you want to make available to them. Then broadcast that selectively. The company that can teach consumers how to do this, and own that management tool is in a very powerful position. The portals will be duking it out with the mobile carriers for this, I suspect.

MSN's vision is pretty parallel to the one above. Irving claims Microsoft has an "ABCH" -- Address Book Clearing House -- that is a repository for all those contacts, relationships and permissions that come from Messenger and Hotmail. You can imagine how powerful that might be -- we're not just talking "gleams" and sharing playlists here -- and how much grief Microsoft will get for playing Big Brother.

Anyway, MSN gets it.

Besides the fact that I'm one of the program managers for ABCH and thus it's kind of cool to get a shout out from our VP, there are some other things about this excerpt that have me smiling. When I first came to MSN I thought I'd have to beat people over the head with the message that Social Software is the Platform of the Future but I didn't have to because everybody gets it. Everyone I've talked to from vice presidents and general managers to developers and testers working directly on individual features has their mind wrapped around our social software vision. It's really simple, the #1 goal of social software should be around improving the ways I communicate and interact with the people I know and a secondary goal is giving me avenues to communicate and interact with people I don't. It's really that simple.

We definitely have some interesting stuff coming down the road in the next couple of months. I can only hope our users have as much fun using our software as we had building it.

On an unrelated note, I have updated the track of the week from my high school days on my space. Just click on the play button on the Windows Media player module to hear this week's track. Listening to some of this stuff I can't help thinking, "I could have been a contender". :)


Categories: MSN

As I mentioned a few weeks ago, we plan to ship an alpha of the next version of RSS Bandit [codenamed Nightcrawler] next week. So far we've been making some progress towards that goal. I checked in the changes to enable marking items as read or flagging them from the newspaper view and I've already found it to be quite useful. A screenshot is below

I've also been hard at work implementing support for synchronization with Newsgator Online via the Newsgator API. It's been more difficult than I expected but I'm sure our users will love being able to move between a web based aggregator or a desktop aggregator as the need arises but have their subscriptions and items they've read stay consistent between both places. Ideally the experience should be the same as moving back and forth between Web mail (e.g. Hotmail) and a desktop mail reader (e.g. Outlook Express).

I've also completed our support for Atom 1.0 and tested against a number of known Atom 1.0 feeds in the wild.

Torsten is working on the new subscription wizard and the podcasting support which should be finally checked in by next week. 

By the way Torsten has started an RSS Bandit new logo design contest and we'd appreciate your comments. It seems a lot of our users who use RSS Bandit from their place of work feel our current smily face icon and logo are unprofessional. I don't mind changing our application icon but would probably like to keep the smily bandit in the logo.

So it looks like we are on track for having the installer for the Nightcrawler alpha available next week. Hope you guys like the new features.


Categories: RSS Bandit

Today I stumbled on the post "Sign up for Gmail"on the Google blog and I was stunned by the following excerpt

For the last 16 months, a lot of people have been asking us how they can sign up for Gmail, and today we're happy to be able to say, "Just go to" From there, you can get an invitation code sent to your mobile phone, and with this code, you can create a Gmail account. Once you have Gmail, you can try out our brand new IM and voice service, Google Talk.

Why use mobile phones? It's a way to help us verify that an account is being created by a real person, and that one person isn't creating thousands of accounts. We want to keep our system as spam-free as possible, and making sure accounts are used by real people is one way to do that.

The privacy implications of having a company collect people's verified mobile phone numbers just for free email accounts boggles the mind. It is common knowledge that web surfers often give websites information they consider private thus I'm sure lots of people will take them up on their offer.  Looking at the GMail SMS mail sign up page it boldly states they plan to store the phone number indefinitely and then points to a privacy policy that doesn't say anything about what they plan to do with our phone numbers. Is their legal team asleep at the wheel or something?

I guess once they ship whatever mobile services that emerge from their purchase of Dodgeball and Android, they'll have a ready pool of phone numbers to launch the service with. That's just genius. Almost evil genius.


There were two instant messaging releases shipped yesterday from two of the major online players.

  1. Google Talk Beta: Google has finally shipped an instant messaging application as we all expected. You can get the scoop from Joe Beda's post Welcome To Google Talk. It seems Joe is one of the folks at Google who helped ship this. From his post we learn they provide
    • Instant messaging server based on the XMPP/Jabber protocol.  This is an IETF approved protocol.  Check out for more info.
    • Out of the box support for many third party clients.  Choose iChat, Gaim, Trillian or a host of others.  We support them from day one.
    • Our own client available for download from  We've concentrated on a simple to use and clean interface.  We've tried to strip IM down to its essence.
    • Support for voice calls between clients that just work.  We've worked hard to support all sorts of network topologies.  We are also using first class industry leading audio codecs.
    • A commitment to openness moving forward.  Choose your platform (Window, Mac, Linux, etc), choose your client (ours or others) and choose your service provider (we are commited to federation).  We want to make IM as open as the web or email.
  2. MSN Messenger 7.5: MSN shipped to its instant messaging client yesterday. You can get the scoop in Leah Pearlman's post MSN Messenger 7.5 - I can't believe It's Not Beta. From her post we learn that some of the new features are
    • Dynamic Backgrounds: Backgrounds that subtly animate in cool ways.

    • Voice Clip: Press and hold the Voice Clip button (or F2) and record up to 15 seconds of your voice or anything. When you release, it goes to your buddies just like an IM, and they can hear it instantly upon receipt.
    • Freaking Awesome Audio Quality Improvements: Yes, that’s the technical name. Our new audio technology makes free Voice (Voip) calls super-clear. Mostly thanks to much improved echo-cancellation. It’s now just like using a phone except: "Look ma! No hands!"
    • Patching: Due to the plethora of features in the Messenger client the download size has grown. In the future, instead of having to download the entire client each time an particular release is updated, we can download a small patch, on the order of 100K on to the user’s machine instead.

Google's entrance into the instant messaging landscape is interesting although unsurprising. As usual Google has entered the space with a disruptive move but instead of the move being the feature set of its IM client it is by not treating their IM network as a walled garden as AOL, MSN and Yahoo! have done. People aren't restricted to the Google Talk client and anyone can write a client application to connect people within their network. I'm not sure this is a smart move but it definitely is a disruptive one.