Windows Live Data Wants To Be Free – Or A Gadget In Every Pot

I walked into my boss's office on my first day back working for Microsoft in April and he asked me for a favor. Four months later, including one month spent working 7 day weeks, the "favor" is finally over. Microsoft just announced the public availability of the Windows Live Contacts Gadget beta. The gadget allows any website, anywhere, without filling out any paperwork, just by including some Javascript, to allow its users to use data from their Windows Live Contacts (i.e. their address book including e-mails, phone numbers, physical addresses, etc.) on the site. But, of course, that's not even half the story.

Continue reading Windows Live Data Wants To Be Free – Or A Gadget In Every
Pot

Personal Web Services – The Unnecessary Business

When I think of say e-mail or IM or web pages or personalized home pages or single sign on or address books, I realize that there is really no good excuse, certainly not in the long run, for these services to be delivered in a centralized fashion. Why can't I just have a little box off in a corner of my house hooked up to my Internet connection that provides these services for me? Why can't I have my own little e-mail, IM and web server that hosts all of my content? At the very least I would maintain my privacy, something I have no hope of maintaining when a 3rd party hosts my content for me (even if the hosting service doesn't peak, doesn't leak and isn't hacked, I can safely assume the government is looking). But in addition to privacy I would also get better functionality since my little box would 'over provisioned' compared to the processing power allocated to users in a typical centralized service.

Continue reading Personal Web Services – The Unnecessary Business

Optimistic Concurrency – A False Panacea

As soon as an Internet scale service expects to allow clients to both read and write data it's a sure bet that optimistic concurrency will come up. After all, how else do you solve the lost update problem without drowning in a sea of performance crippling locks? Better yet, implementing optimistic concurrency in a service is pretty trivial. You just need some kind of change indication system (dates, e-tags, updategrams, etc.) and a 1/2 decent transactioning system (available off the shelf) and you're pretty much done. But unfortunately all optimistic concurrency does is move the 'lost update' lump under the carpet and make it the client's problem. Moving the lump isn't bad but it does mean that before declaring victory you absolutely must be sure that your clients have a workable solution for the merge issue.

[Ed. Note: I updated the article in response to a number of comments on the web.]

Continue reading Optimistic Concurrency – A False Panacea

Thoughts On Creating An Infoset For Windows Live Services Platform

As part of creating a service platform, e.g. a platform focused on the creation and consumption of services by other services, we realized that we needed a consistent way to model messages within our system. This isn't about creating some universal message model for everyone, everywhere. This is strictly about creating a message model for our use. But I think the issues we are dealing with are fairly universal so I thought it would be interesting to share our current thinking. Please keep in mind that this is all very preliminary and subject to change without notice.

[Note: Updated to add a section on extensibility]

Continue reading Thoughts On Creating An Infoset For Windows Live Services
Platform

Adding Extensibility to JSON Data Formats

How does one version a JSON message? How does one make it backwards or forward compatible? This may not be an issue when one's own Javascript is talking to one's own server via JSON but once you throw in creative use of script tags with src attributes or environments other than the browser these issues become relevant.

Continue reading Adding Extensibility to JSON Data Formats

Adding Namespaces to JSON

As part of my job I am thinking deep thoughts about what protocols Windows Live should expose and right now I'm pushing hard for JSON to be a premier protocol data format. I like JSON because it makes it extremely easy to persist hierarchical data structures which account for the bulk of the messages that Windows Live needs to move around. But JSON does have a number of issues that I think need to be addressed, specifically: namespaces, extensibility, schema/type support and relative linking. In this article I make a proposal for how to address namespaces. I will address the other issues in future articles.

Continue reading Adding Namespaces to JSON