(Transcript) Don Box and Chris Anderson Explain "Oslo" in 5 Minutes [actually 6 minutes and 32 seconds]
This post is an edited transcript of the short video on https://channel9.msdn.com/posts/Dan/C9-Bytes-Don-and-Chris-explain-Oslo-in-5-minutes/. Even though the video is from October 2008 and slightly dated, it contains some helpful insights about the motivations behind “Oslo” and some of the thinking of “Oslo” architects such as Don and Chris. For that reason we wanted to make the discussion accessible in (mildly edited) text.
OK, “Oslo”. Assuming that I know nothing about “Oslo”, what is it? What’s the explanation for average developer?
Don: “Oslo” is three things: a tool for interacting with information [“Quadrant”], a language for creating and manipulating information [“M”], and it’s a repository for storing that information.
Why are we building it? Because we believe there is great value in writing software that’s more and more declarative, more and more data-driven, where the data that you’re writing down is more closely aligned with the problem domain that you’re trying to deal with rather than MSIL or x86 assembler.
Does this replace other technologies like WCF and WPF, that you both worked on?
Chris: No, it’s not a replacement solution. We see ourselves as being 15 years into a 30-year journey toward being more and more declarative, more and more data-driven. Think of WCF with its configuration system, WPF with XAML, WF with the ability to describe whole program flows in structured data—we’ve been moving down this path for quite a long time. We really view “Oslo” as the next step in the path where you go from a suite of data solutions where some people bet on config, some people bet on XAML, some people do database things, to a holistic solution that lets people build tools and suites and systems on top of a common data runtime.
Don: Like when we did XAML, you didn’t have to rip out all of your code. Yes, it is possible to write a complete program in XAML, in appropriate scenarios, but that isn’t necessarily what you want to do all the time.
So what are the killer scenarios for “Oslo”? When is “Oslo” the right thing? What do you see as the key scenarios that you’re really targeting?
Don: Many of us on the team came from middle-tier, server-side technologies, and if you look at a typical WF/WCF application, there’s a sea of data that’s used to create that. There’s a contract footprint, a fair amount of config footprint, and then—oh yes—there’s also this code you write which is some of the logic. When I throw WF into that mix, a lot of that logic also gets expressed as data. But it’s smeared across a bunch of different ways to write it down. So I think the value proposition of what we’re doing in “Oslo” is immediately visible if you take a look at an existing WF/WCF app that’s written in the current technologies. That’s one scenario.
Is “Oslo” just about the middle-tier or are you looking to where you can code-gen XAML?
Chris: People confuse what we’re doing in “Oslo” with code-generation which is very traditionally how we did modeling systems: you wrote some description or drew some pictures and that generation thousands of code artifacts. In fact, if you look at early versions of WPF, we use to do code-gen with tons and tons of C# files. We eventually found out that going with a data-driven approach and having the WPF runtime itself understand a model-driven approach improved performance in many ways.
Don: And made the engineering hygiene better.
Chris: Way better. And so I think there are many interesting spaces to also go into on the client. I imagine a set of scenarios with parsing user input, where they type a string in and I can [in the program] understand what they wrote. I can use portion of “Oslo” to do just that. And if you start with the tiny micro-scenarios I think there’s an immediate value [with CTP bits today] to an incredible number of applications from client to server to middle-tier, etc. As the technology developers you’ll be able to incrementally add value from there.