Will this work for launching nested actors?

[testingHotAir]

I also use variant attributes to look up both available actors and queues of launched actors.  Glad to see it's a common solution!

[drjdpowell]

What is this a "common solution" to?  What is the use case of looking up actors by a string?

[AristosQueue (NI)]

> What is the use case of looking up actors by a string?

Debugging only, I hope.

But some people have strapped a dynamic registration layer on top of actors. Some of those users have even built successful applications...

[justACS]

Plug-ins with a common API that don't have to talk to each other, where a human being may want to send messages to a specific plug-in.  Using the enqueuer as a unique identifier is all well and good, but it's not human-readable.  It's corner case, but I've seen it a couple of times.

[jon_mcbee]

My use case is in line with niACS comment above.  I have an application that allows an operator to load up devices at runtime.  Each device is an actor and I use a variant attribute table to keep track of devices and their enqueuers (in my example the key for the VAT is a GUID for the device as read in from a database and not the actors name).  The operator can then load up a test script that exercises the devices, where test steps reference the same GUID.  In reality there are more layers to the application, but this gives a simplified use case.

I am surprised that this usage is considered a corner case, I have multiple applications that have some flavor of this design, and all have been running fine.

[drjdpowell]

I can see how string-lookup can come into things if one is providing a scripting language to the Operator.   And possibly with plugins in general.   Though I've found arrays more natural there, as if the User selects a from a listbox or pull-down menu of actors, it's an index into an array that the code handles.   Using the same Text for the UI and for internal identification is not obvious (unless you are explicitly creating a scripting language) as it ties UI and code logic together.   

But anyway, is this the use case of the original poster?    He seemed to think the use case was having his App be “expandable” because he didn’t have to write as much code to add an actor**.   And his example showed a hard-coded string identifier of a specific Actor; I hope he’s not planning on doing that in an actual application.

—  James

**The secret to less code with clusters is the use of cluster-to-array and array-to-cluster.   Launch your actors as an array, then convert to a cluster and unbundle by name (and use cluster to array when you need to talk to every actor).

[dsavir]

I think the use case would be in a program similar to the Measurement Utility of Elija Kerry. In this case, the user wants *this* measurement and not the other one, so you need to have a simple way to translate the measurement chosen by the user (string) to the actual actor to launch. He uses a variant dictionary there as well.

[AristosQueue (NI)]

Providing a human-readable alternative to the enqueuer refnum is equivalent to debugging use case in my book. It works identically to using the enqueuer refnum, it just makes it easier to figure out where things are going in the system. Where it goes in a different direction is when you start having the ability to lookup the enqueuer by name. As soon as you start building that listener framework, then you've got a major change to the intent of the Actor tree.

[StevenHowell_XOM]

I understand what you are saying, however my question is...if I have a parent actor launch multiple children nested actors, and I need to send a message to a specific one, how do I do that using just the enqueuer references? Wont I need a human-readable reference so that I know which Queue I am sending the message to? Am I missing some native functionality built into the AF or an API? -Steven

[AristosQueue (NI)]

Steven: You and I are talking about two different things, I believe.

You're talking about having a local lookup table for mapping some user selection (say a ring or a typed-in string) onto the particular enqueuer refnum. That table would be used *locally* to pick from one of the enqueuers that the caller actor originally launched and send it a message.

When we talk about "given the actor a name", we mean giving it a name that can be used *globally* to find the actor and be able to send messages to it *by name* instead of having to be given the enqueuer by someone in order to send messages.

One is a local name. The other is a global name. It is the latter that is the problem.