David Treadwell has a blog post on the Windows Live Developer blog entitled David Treadwell on New and Updated Windows Live Platform Services where he previews some of the announcements that folks will get to dig into at MIX 08. There are a lot of items of note in his post but there is some stuff that stands out that I felt was worth calling out.

Windows Live Messenger Library (new to beta) – “Develop your own IM experience”

We are also opening up the Windows Live Messenger network for third-party web sites to reach the 300 million+ Windows Live Messenger users. The library is a JavaScript client API, so the user experience is primarily defined by the third party. When a third party integrates the Windows Live Messenger Library into their site they can define the look & feel to create their own IM experience. Unlike the existing third party wrappers for the MSN Protocol (the underlying protocol for Windows Live Messenger) the Windows Live Messenger Library securely authenticates users, therefore their Windows Live ID credentials are safe.

A couple of months ago we announced the Windows Live Messenger IM Control which enables you to embed an AJAX instant messaging window on any webpage so people can start IM conversations with you. I have one placed at http://carnage4life.spaces.live.com and it’s cool to have random readers of my blog start up conversations with me in the middle of my work day or at home via the IM control.

The team who delivered this has been hard at work and now they’ve built a library that enables any developer to build similar experiences on top of the Windows Live Messenger network. Completely customized IM integration is now available for anyone that wants it.  Sweet. Kudos to Keiji, Steve Gordon, Siebe and everyone else who had something to do with this for getting it out the door.

An interesting tidbit is that the library was developed in Script#. Three cheers for code generation.

Contacts API (progressed to Beta) – “Bring your friends”

Our goal is to help developers keep users at the center of their experience by letting them control their data and contact portability, while keeping their personal information private. A big step forward in that effort is today’s release to beta of Windows Live Contacts API. Web developers can use this API in production to enable their customers to transfer and share their contacts lists in a secure, trustworthy way (i.e., no more screen scraping)—a great step on the road toward data portability. (For more on Microsoft’s view on data portability, check out Inder Sethi’s video.) By creating an optimized mode for invitations, it allows users to share only the minimum amount of information required to invite friends to a site, this includes firstname / lastname / preferred email address. The Contacts API uses the new Windows Live ID Delegated Authentication framework; you can find out more here.

A lot of the hubbub around “data portability” has really been about exporting contact lists. Those of us working on the Contacts platform at Windows Live realize that there is a great demand for users to be able to access their social graph data securely from non-Microsoft services.  

The Windows Live Contacts API provides a way for Windows Live users to give an application permission to access their contact list in Windows Live (i.e. Hotmail address book/Live Messenger buddy list) without giving the application their username and password. It is our plan to kill the password anti-pattern when it comes to Windows Live services. If you are a developer of an application or Web site that screen scrapes Hotmail contacts, I’d suggest taking a look at this API instead of continuing in this unsavory practice.

Atom Publishing Protocol (AtomPub) as the future direction

Microsoft is making a large investment in unifying our developer platform protocols for services on the open, standards-based Atom format (RFC 4287) and the Atom Publishing Protocol (RFC 5023). At MIX we are enabling several new Live services with AtomPub endpoints which enable any HTTP-aware application to easily consume Atom feeds of photos and for unstructured application storage (see below for more details). Or you can use any Atom-aware public tools or libraries, such as .NET WCF Syndication to read or write these cloud service-based feeds.

In addition, these same protocols and the same services are now ADO.NET Data Services (formerly known as “ Project Astoria”) compatible. This means we now support LINQ queries from .NET code directly against our service endpoints, leveraging a large amount of existing knowledge and tooling shared with on-premise SQL deployments.

The first question that probably pops into the mind of regular readers of my blog is, “What happened to Web3S and all that talk about AtomPub not being a general purpose editing format for the Web?”. The fact is when we listened to the community of Web developers the feedback was overwhelmingly clear that people would prefer if we worked together with the community to make AtomPub work for the scenarios we felt it wasn’t suited for than Microsoft creating a competing proprietary protocol.

We listened and now here we are. If you are interested in the technical details of how Microsoft plans to use AtomPub and how we’ve dealt with the various issues we originally had with the protocol. I suggest subscribing to the Astoria team’s blog and check out the various posts on this topic by Pablo Castro. There’s a good post by Pablo discussing how Astoria describes relations between elements in AtomPub and suggests a mechanism for doing inline expansion of links. I’ll be providing my thoughts on each of Pablo’s posts and the responses as I find time during the coming weeks.

Windows Live Photo API (CTP Refresh with AtomPub end point)

The Windows Live Photo API allows users to securely grant permission (via Delegated Authentication) for a third party web site to create/read/update/delete on their photos store in Windows Live. The Photo API refresh has several things which make it easier and faster for third parties to implement.

• Third party web sites can you link/refer to images directly from the web browser so they no longer need to proxy images, and effectively save on image bandwidth bills.
• A new AtomPub end point which makes it even easier to integrate.

At the current time, I can’t find the AtomPub endpoint but that’s probably because the documentation hasn’t been refreshed. Moving the API to AtomPub is one of the consequences of the decision to standardize on AtomPub for Web services provided by Windows Live. Although I was part of the original decision to expose the API using WebDAV, I like the fact that all of our APIs will utilize a standard protocol and can take advantage of the breadth of Atom and AtomPub libraries that exist on various platforms.

I need to track down the AtomPub end point so I can compare and contrast it to the WebDAV version to see what we’ve gained and/or lost in the translation. Stay tuned.

Now playing: Jay-Z - Can't Knock the Hustle