Another Side of Fast Internet

As a part of my current project, I needed to get contact information for my application. It was required for a simple task of getting information about these contacts’ availability information. Which, itself, is a simple thing to do using Exchange Web Services Managed API. The problem, however, is hidden in the fact that as an input I need to provide users email addresses. And now the hard question comes in.

How can developer get contact names of people user works with given the fact user has Exchange account and these people are represented as users in that Exchange server?

You can think it’s easy – just copy all contacts from user’s “Contacts” folder from Exchange (which means you build a cache) and show contacts list to user in order to let user choose those people whose availability she is interested in.

Unfortunately, it would be easy in case people user is going to interact with are stored in his “Contacts” folder.

As a back note, my experience of everyday Exchange user lasts for almost 5 years since I’ve installed my own version of Exchange (from MSDN Subscription) back when I was studying Computer Science in my university, and then as Microsoft’s employee.

The problem is, typically when you use Outlook as your main rich client you almost don’t need to save your colleagues information into your Contacts folder. Why? Because you anyway know their names, and when you write them emails, you just type in names, and Outlook auto-resolves them into email addresses. The only need to save contacts appears when you want to reach your colleagues by phone. But here is another interesting thing – Outlook doesn’t store email addresses of Exchange users in your Contacts folder in a standard way “username@domain”. Instead, it uses Exchange format for that thing, and a typical record will look something like this:


Sometimes the record can be represented like the following one:

“/O=microsoft/OU=northamerica/cn=Recipients/cn=t-daniek”, and last thing is obviously a “username” part in a standard email representation.

But this is not always the case. Interesting thing is, when you open Outlook Inspector window (which is kind of Editor for any Outlook item), and go to emails of user, you’ll see typical emails in a standard form. The fact is, Outlook actually auto-resolves that long Exchange address into friendly one, and somehow does that job very fast.

The problem is, when you deal with Outlook interop APIs, you can’t get that feature of auto-resolve, and when you iterate over contacts stored in your Outlook, you’ll get those Exchange-formatted email addresses.

Back to the scenario I’m working on, I have to say it’s quite easy to show list of contacts for user to choose from, but getting their emails in case they are Exchange users is a pain that requires time (it took about 1 min to get Resolve function of Exchange Web Services Managed API to provide me the data I needed about just 7 contacts, and my app was in work environment with quick access to Exchange server) to be solved.

Of course, asynchronous requests can & will help a lot, but the most interesting thing I’ve learned from this thing is simple:

Access to fast Internet makes caching of online data almost not required!

Certainly, it was predicted many years ago, but the fact that that time is almost here, is a beautiful finding.

But a back side of the story is, we became much more dependant on fast Internet access that ever before.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s