Microsoft Messenger Architect On The Future Of IM

CowboyRobot writes "ACM Queue has an interview with Peter Ford, chief architect for MSN Messenger, by Eric Allman, CTO of Sendmail. They discuss the present and future states of IM, the current big players as industry shuffles toward standardization, some of the social implications of IM versus email or telephone, and technical issues such as using SIP as opposed to XMPP (Microsoft is pushing for SIP, everyone else seems to favor XMPP). They don't bring up Wallop, Microsoft's community application that will be built into Longhorn, but that's surely part of the long-term discussion."

Comments

Cross-platform IM solutions with apt-get

[Debian Troll's Best]

This story really reminds me of some work I did a few years back as a contractor in a large aerospace company. The problem they were facing at the time was a need to roll out an enterprise-wide messaging system (management was actually quite clued-up about the potential of IM to empower E2E (employee to employee) communication), but there was a very heterogeneous mix of clients. Management used Windows, the engineers used Solaris and Irix the software developers used Linux, and the system administrators ran the whole back end on OS/390. There seemed to be no real solution to the problem: how to bring an instant messaging system to all platforms, and preferably, one which was based around an open source platform. I could, however, see the solution where other's couldn't: apt-get.

Basically, apt-get is a kick-ass system for making sure your Debian system is up to date, has the latest packages installed, and manages conflicts. At the core, what is an IM system about? Making sure your message 'packages' are up to date, has the latest messages 'installed', and manages conflicts, that is, a reply had been requested, yet hasn't been sent! All the key infrastructure was already in place, including an interface (dselect), which could easily be ported to all the required platforms to allow easy reading and sending of instant messages.

The first step was to use apt-get itself to distribute a modified apt.sources file, which contained the IP addresses of all of the IM clients on the network. Some people had suggested DNS as a solution to this, but my feeling was that DNS wouldn't scale so well (this was a large LAN, with over 10,000 clients...I'd like to see DNS cope with that!!). Once each client had it's apt.sources file updated, you could basically send a 'message' (your ASCII message encapsulated into a .deb file by a custom packager I created that runs as a background process) to any host specified in the apt.sources file. To do this, I had to create a daemon-ized version of apt-get, listening on a predefined port. The daemon would be contacted by the apt-get client, would receive the .deb package containing the message, and then 'install' it to the dselect based client on the receiving system.

Without trying to sound like I'm blowing my own trumpet, the system was a huge success, and the many features of apt-get for package management really came in handy for managing IM flows. For instance, just say you've just sent a message to a colleague via apt-get saying "Let's meet for lunch at 1pm":

apt-get install host=fred-pc "Let's meet for lunch at 1pm"

But then...you're called into an emergency meeting and you can't make lunch until 2pm. You need to 'upgrade' your message to the latest version:

apt-get upgrade host=fred-pc "Make that 2pm!"

Easy! The whole project was essentially wrapped up in 6 months, and because of the open-source nature of apt-get, we'd managed to port to all of the platforms in our specification. If Microsoft can swallow their pride a little, I think they could really learn something from the power of apt-get!