Yesterday, the Outlook Team at Microsoft unveiled via their blog (and by Kurt DelBene’s demo at PDC09) information about the release of the Outlook Social Connector (OSC). I also briefly discussed it in my last blog, which was written before I even read their blog (thanks to my notes from a private demonstration by the Outlook Team at the MVP Summit last year). Today, Outlook Development Program Manager Randy Byrne has released the developer documentation on MSDN:
Developing an Outlook Social Connector Provider:
http://msdn.microsoft.com/en-us/library/ee829696(office.14).aspx
This post will review and distil and criticize and applaud where appropriate. Let’s go!
Old School Implementation
OSC providers need to be built as a COM-visible DLL – which is not surprising. What’s interesting is that you have a choice of using either unmanaged languages like C++ or managed languages like VB.NET and C# to build them. The documentation is also very clear – and states this twice – that you should use a native C++ compiler for production providers in order to minimize the download size of the provider and to minimize provider load time.
However, if you can depend on the availability or deployment of the .NET Framework 3.5 SP1, managed providers are fine. I’m going to guess that social networking providers themselves may opt for unmanaged providers, while the technical community, businesses and small ISVs may choose to develop managed providers.
Requirements
There’s no need to rehash everything the article already states, but the first requirement for your first project is to set a reference to the socialprovider.dll assembly, which exposes the interfaces for Microsoft Outlook Social Provider Extensibility.
The Interfaces – Not Ready For Prime Time?
Essentially, the implementation for your custom provider needs to handle four interfaces:
- ISocialProvider
- ISocialSession
- ISocialProfile
- ISocialPerson
What’s odd are the number of methods/properties that are not supported in release 1.0 of the OSC:
- ISocialProvider.DefaultSiteUrls – a list of URLs are supported, but only the first (the default) will be used
- ISocialProvider.GetStatusSettings
- ISocialSession.FindPerson
- ISocialProfile.AreFriendsOrColleagues
- ISocialProfile.SetStatus
- ISocialPerson.GetStatus
The most obvious glaring omission is the current lack of support for social statuses. That’s a big one! This could very well prevent any Twitter (and Facebook or any other social networks where status is uber-critical) providers from being fully developed at this time in the Beta. Although using ISocialProfile.GetActivities may be the mechanism to retrieve a full list of status updates, it remains to be seen how the UI in the People Pane will treat activity feeds if they are used to display statuses that may be completely different entities compared to activities (depending on the social network). I imagine the title strip in the People Pane is where status updates are supposed to be displayed, so hopefully this can be cleared up soon.
I’m also not clear on the difference between ISocialSession.FindPerson and ISocialSession.GetPerson. The former – not implemented yet – returns a String and the latter returns a full ISocialPerson interface (both take userID strings as a parameter). Hopefully this is something that can be ignored for beta providers without handicapping the feature set.
Authentication – Not For The Corporate Domain??
The ISocialSession interface is what is needed to authenticate with your social network. It supports two methods – Logon and LogonWeb. Logon is meant for basic authentication mechanisms – so a simple username and password implementation. LogonWeb is to be used for forms based authentication. Both are fine of course and can be used for the majority of social networks. But what about Windows Authentication?? What if your provider is leveraging domain resources and Active Directory? It’s unclear to me whether we can leverage the System.Net.NetworkCredential class and use the identity of the logged on user to sign into domain based resources utilized by the provider. It sounds like providers may need to ask the user to enter their username and password – and store and encrypt them – in order to let the provider sign in to the domain the user is already logged into! This approach won’t be very elegant, but may need to be swallowed for this version. Hopefully the next rev for the OSC provides additional authentication methods – especially Windows Authentication for providers that may be leveraging LOB systems.
A Walkthrough Of The Sample Project
A Visual Studio project is available for download so that you can see how the interfaces are implemented:
Outlook 2010 Sample - Social Connector Provider
I ran the project and stepped through the code to briefly see it in action. There’s no point going into detail about the order of events in the various interfaces – I just want to see what the sample provider really does. So the first thing I did was add the TestProvider network:
Clicking Connect validated my login (any username or password can be used for this project):
Great – I’m in. So now what? I tried adding myself to the TestProvider network:
This didn’t do much but create an ugly icon:
The tooltip on the icon said “Unable to add person on TestProvider. Please try again later”. Okay, that’s fine. This is a sample project and the data is static.
So what else can we do? Check this out – by setting the proper registry keys (HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\SocialConnector – set ShowDebugButtons to 1), you can enable the display of some buttons in the Add-Ins tab on the Ribbon for testing purposes:
I clicked Sync Feeds, and saw a call to the TestProfile.GetActivitiesOfFriendsAndColleagues method which retrieved three activities. So where are the activities? Look here:
It looks like Activities from all providers are stored in the News Feed folder. I was under the impression that provider storage utilized provider-specific sub-folders. More on that in a sec…
I then clicked the Sync Contacts button, which did create a provider-specific Contacts folder…
…and added two new Contacts to it. I’m not sure why the user name is included in the folder name along with the name of the provider (TestProvider – foo). Maybe there’s a need to allow signing in to a provider’s social network using multiple accounts and keeping your Contacts separate per user.
Another interesting thing is that the People Pane is also visible in the Contact form:
Here you can see the same entries in the News Feed folder in the All Items view (as aggregated from the Activities view).
Conclusion
So developing a provider seems pretty straightforward. There are considerations for best practices as listed in the MSDN article. The main points of consideration are to get a handle on the deployment requirements regarding the necessary registry keys for provider registration, and to be aware of the effects from making a high volume of calls to the social network from your provider.
Watch this space for more information as I dig deeper!
Note: Keep an eye on the Outlook Team Blog for more information about provider extensibility from Randy Byrne.