An updated draft of the DLR Hosting Spec has been released. This document covers hosting DLR-based languages with a focus on Silverlight, MerlinWeb, and interactive consoles. As it is just a draft, many of the developer notes explaining what they are trying to accomplish are still present.
The scenarios Microsoft is trying to support include:
- SilverLight hosting in browsers
- MerlinWeb on the server
- Interaction consoles where the ScriptRuntime is possibly isolated in another app domain.
- Editing tool with colorization, completion, and parameter tips (may only work on live objects in v1)
- PowerShell, C#, and VB.NET code using dynamic objects and operating on them dynamically in the same app domain
Three levels of hosting are defined in the spec. Their introductions are quoted below:
Level One -- Script Runtimes, Scopes, and Executing Files and Snippets
For simple application programmability, you want to provide a host object model that dynamic language code can use. You then want to execute files of code that consume that object model. You may also want to get the values of variables from the dynamic language code to use dynamic functions as command implementations or event handlers.
Level Two -- Engines, Compiled Code, Sources, and Object Operations
The next level of engagement involves operating directly with engines and abstractions of source code and compiled code. You can compile code and run it in any scope or its default scope. You also have more control over how you provide sources to the DLR.
Level Three -- Full Control, Remoting, Tool Support, and More
Level three engagement as a host gives you full control over the ScriptRuntime. There are many things hosts can do at this level from controlling runtime configuration, to handling runtime exceptions, to using remote ScriptRuntimes, to providing full programming tool support with completion, parameter info pop-ups, and colorization.
The balance of the spec is the API definition itself and quite a few code samples. You can get the DLR Hosting Spec from John Lam's blog.
