I imagine that most developers when presented with the concept of Silverlight have a very joyous first response. And then the next thought is a pragmatic one of wondering how much code (source or binaries) can be shared between Orcas and Silverlight. In the past, I've come across some pretty interesting uses of ASP.NET to share experiences across both the server and the offline client. Today, I'm pretty sure that we can offer a better scenario than that.

Before we go into details, let's talk scenarios. My dream scenario is that TurboTax would move their web-based version to Silverlight, and their client version to full WPF. For the Silverlight version, I'm thinking of a pretty immersive application, along the lines of the nibbles tutorial or the new Tafiti search app. I can easily see a major improvement in customer experience, including for me, a multi-year TurboTax customer.

The question on the table is the degree to which Turbotax developers (for my dream scenario) could share code across those two presentations of Silverlight. There are two parts of that: the UI layer (WPF code, xaml and other assets), and then the business logic. Although possibly the most interesting topic, I won't address the UI at this point since the WPF and Jolt teams are still working out the kinks on that issue. The business logic aspect of the issue is well within the purview of what I've been working on.

Our goal for business logic has been pretty simple: subset the existing Orcas stack for the BCL, XML and other base technologies in a very, very compatible way. We want folks to be able to take their Silverlight business logic, and re-use it on the desktop. For Turbotax, you could imagine them being able to port all the code that calculates your taxes against the static IRS tax tables to Orcas. At this point, we're focussed on making source re-use work really well. Binary porting is definitely something that's on our list, but not what we consider to be the mainline scenario since you'll need to re-compile your UI code anyway. I'd like your feedback on it if you have a differing opinion.

You might notice that I'm talking about porting code from Silverlight *to* Orcas. The reverse direction isn't nearly as compelling. By definition, Silverlight will always be a subset of Orcas, and your Orcas code may have a lot of dependencies on types that are only part of Orcas. Starting from Silverlight, you know that all of the APIs that you use will also be on Orcas, and you're experience porting to Orcas will be straightforward.

One kink is that we've added APIs to Silverlight that are not in Orcas. So, my story as described above is actually a little flawed. Naturally, we'll add those to the next desktop release after Orcas, but there is a question of how to deal with that in the meantime. We do have a solution for that that we're working on. I'll post on that when I have firm details available.