I noticed this question in a comment to Rob Blackwell’s Reg article on Silverlight:

…given that MS never does anything without a commercial reason … why Silverlight? What sales will it make? What competition will it kill? As far as I can see, there’s nothing that will tie SL exclusively to a particular MS product.

Answer: it’s all about the platform stack. Microsoft does not want to cede this space to Adobe and Flash, because it is strategic. Use Flash, use Adobe’s tools rather than Visual Studio, use the Java-based LiveCycle and JEE rather than ASP.NET and Windows Server. Use Silverlight, use Visual Studio, ASP.NET, XAML, SQL Server, all the Microsoft stuff.

What about the Internet as an advertising platform? Flash/Silverlight is the client runtime.

What about the Internet as a broadcasting platform? Same story.

I speculated recently about the future of gaming.

Silverlight is partly defensive. In other words, less about “what sales it will make?” than about, “what sales will it avoid losing?” Web developers need to support cross-platform clients; if Microsoft cannot provide the tools and server-side platform to make that work, developers will look elsewhere.

I picked up a hint here at Tech-Ed that SQL Server Compact Edition may find its way into a future Silverlight. A cross-platform local database store makes a lot of sense; Adobe already has this in the form of SQLite. If Adobe’s AIR proves popular, Microsoft could relatively easily push Silverlight in that direction as well, providing a way of running Silverlight outside the browser.

Doesn’t this undermine Windows? Maybe a little, and I am sure this is a point of debate within Microsoft, but it is worth it.

Silverlight’s big problem: devices. Flash on iPhone: possible, even likely. Silverlight on iPhone, Nokia? A stretch.

I’ve just returned from Carl Perry’s Tech Ed session on the Entity Framework, an object-relational library for ADO.NET, initially implemented for SQL Server. Perry is a Senior Program Manager Lead on the SQL Server team. The Entity Framework is the first implementation of what Microsoft calls the Entity Data Model. Generate a data model from a database, tweak the model in Visual Studio’s designer, then generate code to use in combination with LINQ (Language Integrated Query). I found this code snippet from Perry’s slides illuminating:

using (AdventureWorksModel model = new AdventureWorksModel())
{
var query = from c in model.Customer
where c.MiddleName == null
select new {
FirstName = c.FirstName,
LastName = c.LastName,
EmailAddress = c.EmailAddress }; 

foreach (var c in query)
 {
 Response.Write(String.Format("<p>{0}\t{1}\t{2}</p>",
 c.FirstName,
 c.LastName,
 c.EmailAddress));
 }
}

In the above code, AdventureWorksModel is an instance of an Entity Framework model, and as you can see makes for clean strongly-typed coding against the database.

But doesn’t Microsoft already have a shiny new object-relational layer called LINQ to SQL? Why bother with Entity Framework?

There appears to be considerable overlap, but the Entity Framework has higher ambitions. Perry said that LINQ to SQL is fine when your entities map closely to database tables, but Entity Framework is better for more complex mappings. It is not there yet, but it looks as if Microsoft will evolve the framework to enable model-first development and add features like the ability to define constraints in the model. All very familiar in the modeling world. The question may become: why bother with LINQ to SQL?

Entity Framework is not new; for example it is described in this paper from 2006. However, I had not looked at it before in any detail. You can download a beta here.

The media is ga-ga right now about Google’s OpenSocial story but most accounts are missing the key question here, which is about identity rather than APIs. An honourable exception is David Berlind – one of my top 10 tech journalists – who posed an interesting question at a press briefing but received an incomplete answer (a common experience). He asked how identities are mapped between containers.

I’ll explain. OpenSocial is an API for writing social widgets – JavaScript applets which hook into your relationships as expressed by people you’ve added as “friends”. Mark Andreessen has a great overview of the API, which is based on the concept of containers and apps. A container is a site such as MySpace or Orkut, which is where you’ve defined a set of relationships. An app is a widget or other JavaScript application that calls the OpenSocial APIs. The OpenSocial docs, which have just gone live, define a JavaScript API for widgets, and data APIs for People, Activities and Persistence, where Persistence covers retrieving and updating key/value pairs. All the data APIs use the GData protocol.

The big deal about OpenSocial is that many containers will support the same API, making it easier for developers to write apps. For example, music discovery site iLike, already big on FaceBook, can write one app that will more or less work in both MySpace and Orkut. And some new container site can start up, and by supporting the OpenSocial APIs be immediately attractive to developers with existing OpenSocial apps.

That’s definitely an advantage, but who are my friends? My Facebook friends? MySpace friends? Orkut friends? LinkedIn friends? If the social app concept is as big as people think it is (count me as a little sceptical), then the existence of multiple incompatible friend networks will soon become intolerable. Further, if I sign into a new container site, the big barrier to entry is that I have to recreate a friends network on this new site. Some sites workaround this problem in the crudest possible way. You have to give the new container site your username and password for some other container, and it pretends to be you and sucks out your existing contacts.

There is no simple answer to this. Even if you could do it, many people would be reluctant to merge multiple existing networks, because they represent different roles which they want to keep distinct. Social and business are the obvious ones, but that’s just the start.

There are several implications. First, the impact of OpenSocial on Facebook is probably less than some are implying. Facebook’s advantage is its bank of existing accounts and relationships. MySpace has lots of these too; but the arrival of OpenSocial has not changed that fact.

Second, the OpenSocial API is not such a big story yet. The big story will be when common identity gets added to OpenSocial. Right now, we have several containers vying to the one true identity provider for the internet, and a brave but so far unsuccessful effort by OpenID to free us from that alarming prospect. OpenSocial could evolve some federated way to unite identities. Or Google could try to make its Google Account system the center of our digital lives.

The identity wars matter more than the API wars.

Update

Others are also asking about this. Here’s a couple:

Dennis Howlett on a first Enterprise take

Bob Warfield who talks about a meta-social network

I’ll add more info as I find it, or by all means comment.