Dynamo 2.0

It took nearly 3 years for Dynamo to get to 1.0. Getting from 1.0 to 2.0 should take far less time. This document will track the proposed changes to this repository and to the Dynamo API to achieve Dynamo 2.0.

Dynamo will continue to be the embedded computation engine in products like Dynamo for Revit. At the same time, the API needs to evolve to support future applications where Dynamo is used as a service.

Dynamo should contain the object model for the visual programming language, the compilation layer which generates suitable ASTs from that object model, and the Design Script virtual machine which executes those ASTs. All other functionality not related to these purposes, should be relocated.

The Dynamo API should be defined in a stand-alone assembly, Dynamo.API, and be well documented. All changes to the API should adhere to the rules of semantic versioning.

Goals for Dynamo 2.0

• A coherent, idiomatic, API with tooling to enforce that standard.
  • Example: To create a new DynamoModel currently, you must call DynamoModel.Start(...). This is not idiomatic c#. The creation of a new DynamoModel should be available by calling new DynamoModel(...).
• Documentation of all APIs with links to code samples where necessary.
• Decouple the VPL from the current Design Script implementation. Separate AST generation from the NodeModel implementation. By having AST generation on each NodeModel, we've coupled Dynamo to one language, Design Script.
• Strict layering. All functionality not specifically related to the creation or execution of the workspace should be moved to another layer.
  • Example: We currently have the methods DynamoModel.Cut() and DynamoModel.Paste(). Cut and paste functionality should be in the view layer.
  • Example: NodeModel contains properties like IsInput, which are UI concerns.
  • Example: Our RecordableCommand types wrap method calls for the purpose of enabling command playback. But command playback is only used in the context of an application. The wrapped methods should be made public and the recordable command infrastructure should be moved to a separate assembly.
• Unification of Custom Nodes and Workspaces. Simplifying the idea of a workspace.

Proposed Changes to the Dynamo Repository

The Dynamo repository has grown to include DynamoCore, the WPF UI used in Dynamo Studio and Dynamo for Revit, and all of the node libraries shipped with those products. The focus in Dynamo 2.0 will be in making the repository slimmer, representing only Dynamo's core: the graph and the Design Script language, and not all the bits that are parts of Dynamo-based applications. The Dynamo NuGet packages will be the primary mechanism by which associated projects consume the Dynamo APIs.

• Remove all build errors in Dynamo.All.sln
• Remove all node library projects from Dynamo.All.sln.
• Each node library currently residing in core should be moved, along with its testing libraries to individual repositories which are formatted as packages.
• Enable automated build and testing of all node library repositories.
• A Readme and Documentation for all node libraries should be provided in a consistent manner. For documentation, consider using the same framework in place to generate the documentation for the core API.
• Move the DynamoManipulation extension to a separate repository.
• Move the DynamoPackages extension to a separate repository.
• Move DynamoSandbox and DynamoCoreWpf to a separate repository.
• Move the UpdateManager to a separate assembly, UpdateManager.dll
• Move DynamoApplications to a separate assembly.
• Move all issues associated with specific node libraries or Dynamo for Revit to their respective repositories.
• Transfer wiki pages as required.
• Create automatic builds of Dynamo NuGets during build.

Proposed Changes to the Dynamo API

• Make methods called by the RecordableCommand types public, where appropriate, and move RecordableCommands to a separate assembly.
• Remove all InternalsVisibleTo except for testing projects from DynamoCore.
• Move EngineController into Workspace.
• Remove "current" workspace distinction. Enable multiple home workspace support.
• Relocate or internalize all members not defined in Dynamo.API.

Interfaces

There is a half-complete set of interfaces currently available for Dynamo. The goal for 2.0 is to complete these interfaces, and make all existing Dynamo code use these interfaces.

• Rename DynamoCore to Dynamo
• Create Dynamo.Interfaces assembly. Move interfaces for the model here. Reference Dynamo.Interfaces in Dynamo
  • IDynamo
  • INode
  • IWorkspace
  • IConnector
  • IGroup
  • INote
• Replace all references to DynamoCore types with references to their interface.