As I've talked to developers over the years about actor-oriented programming, one consistent message I have heard is that it is more difficult than necessary to transition from one style or framework to another. One way to help remedy this problem is to make side-by-side comparisons available to the community. My hope is that practitioners of various actor-oriented frameworks, toolkits, or methodologies will implement the design using the tools of their choice.
Page 1 of the design document is copied below...
The Car Wash Actor project is the first in a planned series of projects intended to provide the LabVIEW community with examples of how to implement Actor Oriented Programming (AOP) using the various framework and methodologies available. The Car Wash Actor is intended to be an introductory example and to demonstrate to developers who are new to AOP how the basic concepts are implemented.
This project is derived from the Car Wash CLA sample exam and it may be useful to refer to that document while implementing this project. The sample exam leaves many design decisions up to the architect. While that is the correct decision for an exam testing an architect’s ability to create a design, that level of freedom is counter-productive to the purpose of this project. Allowing each architect to make independent design decisions for their implementation makes it more difficult for new AOP developers to compare and contrast the AOP options. For that reason, this project defines many of the design decisions normally left to the architect.
Those implementing this project should follow this design as closely as their framework allows. Any deviations from the design should be identified, an explanation given as to why the framework does not support the design, and a description of how the replacement framework feature works. In particular implementers should not insert code features (e.g. abstraction layers, extension points, plug-ins, dynamic launching actors, etc.) that are not identified in this design. There will be future projects available to explore advanced features of the frameworks.
Implementers should make every effort to ensure all dependencies are included in the provided solution’s zip file. This includes any packages, add-ons, or extensions, even if they are available on the Tools Network. Remember, the goal is to eliminate barriers and make it as easy as possible for users to view and execute the code.
Another key point for implementers to note is while CLA sample exams are not intended to be fully implemented and may not compile, code implementing this project should be fully executable to maximize its value to end users.
This project folder includes a Git repository. Implementers are encouraged to include several commits showing the project as it develops—for example as each component is completed. Being able to see how the code progresses rather than only viewing the finished project provides valuable insight to users. At the same time, implementers should take advantage of Git’s ability to squash commits and only include commits in the final solution that are useful for users to view. In addition to providing explanatory commit comments, tags should be used to identify the completed version 1 and version 2 requirements.
If the project’s Git repository has a large number of hidden objects, implementers may choose to compress the repository prior to distributing it to the community. See Git documentation for details.
 Exceptions can be made if the framework provides no other option. For example, the Actor Framework dynamically launches all actors—other than debug mode, it does not provide a way to not launch an actor dynamically.