Configuration Containment and sharing in Actors

[Mike_King]

I am still wrapping my head around the whole actor framework and starting to implent a larger application with it.  My application is a DAQ system that has user configurable channels (such as scaling, filtering and logging options) and also unit conversion at the UI.  My question is, what is the best way to contain these configurations in a class structure yet share the components between the actors that I have.

So, here is what I am working with essentially (simplified for explanation). 

3 Actors: Main App, Acquire and Logging

Main App actor (Displays via popup, the configuration of channels and the configuration of unit conversions and which channels will display in which units for example)

-This actor passed updates these displays when it receives data back from the Acquire actor then that actually goes to get or calculated the data for display.

Now, The Acquire actor needs to get the current configuration that the user might edit in the Main App and some of the configuration that was loaded from disk at started is also in the main app class.  Should the main app when the config changes, then send this new class to the Acquire via message so it keeps the data in both actors, or is there a better way to do that by reference??

It seems I should contain the configuration that is needed in the Acquire actor, stored in that actor, edit from the UI, but the changes messaged directly to the Acquire actor and never stored in the main app configuration?  Would that make the most sense?

One configuration parameter I have is for the language of choice and this is used by all actors for localization.  What is the best way to ensure that is available to all actors.  At the moment I have it in a global for ease and direct access inside the localization VIs, but obviously that may not be a good solution and wiring it as an input to the localization might be better.

So, I'm looking for ideas on what is best for configuration loading and sharing between actors?

Thanks,

Mike

[CaseyLamers1]

A couple of thoughts.

I would suggest that your Main App actor launches a User Interface actor.  The UI should know how to display updates from the acquire system without having to share its control references.  I would suggest that the Acquire actor should know how to do all of the scaling (and maybe even send raw and scaled values) and then send the data to the UI.  You might send the values to the main app first and have it send the data to the UI or you may create a direct link between the acquire system and the UI.

UI can have localization information and know how to show different views depending on the configuration.

The main app can read a configuration file and pass that file reference to the UI, Acquire and Logging actors when it launches them.

Anything that is configurable should "have a" configuration (that is to say use composition not inheritance).  The reading of the configuration can be the responsibility of the configuration.

I have each class have its own confguration class that "knows" its section name and how to read its configuration (keys) from a file.  I launch things following a tree and when my top level starts it opens a config file and then writes the reference to all of the configuration classes of the things that get launched.

Good liuck,

Casey

[Mike_King]

Thanks Casey,

That makes sense to pass your configuration reference to each actor, but of course, let them deal with their own configurations. I do have my acquire actor sending messages of the scaled and raw data directly to the UI for the UI to then display (because it handles localization and unit conversions at the UI level).

Because the UI is able to modify the configuration at run-time (via user), I will have to add a message to send from the UI back to the Acquire or logging actors to have them handle that config change. I think I will send the changed data to the acquire actor and then have it actually save and apply then new config, just to keep it containted at the responsible actor, despite where the UI change was actually initiated.

Thanks for the suggestions and ideas.  Much appreciated.

Mike

[drjdpowell]

Another idea would be to have the Acquire actor be in charge of implementing its own configuration editor (by whatever means), with the main app asking it to insert this editor in a provided subpanel.  The main UI then doesn't have to be dependant on the details of configuration, and you could easily have a variety of different "Acquire" actor types with different configuration needs.

[Mike_King]

Drjdpowell.    Hmmmm I was thinking something similar in that I could make the acquire actor have the configuration self contained within its actor and classes and the main app just call that by reference because the different acquire modes and drivers will need some different configuration parameters and this would let the configuration then be based on what drivers are implemented dynamically.  i already have confia hardware abstraction layer with a simulator mode that will have some unique configuration so that config ui could message out any behavior changes back to the main ui that it impacts.  Either way they will have some kind of message coupling but id like to still be able to abstract that more using a plugin style config.  Either subpanels or dynamic popups.