Request: lose the "Caller-To-Actor" and "Actor-To-Caller" language

[tst]

AristosQueue wrote:

I'll stand by "enqueuer".

I don't personally mind "enqueuer" (although I do think it might be considerably more difficult than "queue" for many people), but I do want to make sure that the actual point isn't lost - please, for the love of all that is holy, unholy or having various degrees of holiness (including NaN and 87+4i holiness), lose the "Caller-To-Actor" and "Actor-To-Caller" language. Think of the children.

EDIT - This was split from an earlier discussion, so I thought I would clarify the point here. This refers to the terminal names for the Launch Actor VI, which looks something like this (not exactly, but I only had 2011 open, so I simply renamed the terminals):

The "enqueuer" discussion is more general, but the Actor-to-Caller discussion is only really relevant here (although I'm assuming it might also apply in the VIs which return the actor's enqueuers).

[AristosQueue (NI)]

I branched this to a separate discussion thread because this is a separate explicit request to change the AF, rather than more philosophical discussion and/or practical advice on using the framework, the way the other tangents were.

tl;dr is in bold face.

There is a major problem with changing this terminology: you have to tell me what to change it to.

Launch Actor.vi has an enqueuer in and an enqueuer out. They are NOT THE SAME reference. This is, in my observation, very hard for people to grasp because in LabVIEW it is so typical to have "ref in" and "ref out" just for the purposes of stringing the railroad tracks.

The early drafts of the AF used "Recieve Queue" on the input and "Send Queue" on the output. But there was a lot of confusion (I think you can find it archived in the forums) about what perspective to use. Was this from the point of view of the caller or from the point of view of the actor being launched? It was especially bad since the caller's own queue was obtained from a function "Get Send Queue", which you then had to wire to the "Recieve Queue" termninal. Because, of course, a caller's send queue was a nested actor's receive queue. So that was a mess.

We tried "Caller's Send Queue" as the input and "Actor's Send Queue" as the output. There were objections to that that, though I don't recall exactly what they were. I do remember the positive of the current names (which I list below). We tried those names before we had the "enqueuer" term nailed down, so we have NOT tried "Caller's Enqueuer" and "Actor's Enqueuer" -- maybe that would be better?

Many people worked on that renaming, and the current terms were the most descriptive we could find to explain which enqueuer was which. The current names were chosen to make it clear that a bidirectional communication was being established, that there was a relationship between the caller and the actor. That relationship is lost if we reduce down to just "Caller's Enueuer".

So, that's how we got where we are today -- multiple people finding this easier to use than the other names we tried. More peopel are using the AF these days. Perhaps that gives us a better sample size.

Comment away!

[tst]

AristosQueue wrote:

...the current terms were the most descriptive we could find to explain which enqueuer was which

And I think you succeeded in at least making it clear which of the two queues you're talking about*, but that success has come at the price of making the tool less easy to understand and use. I also seem to remember the issue with the send and receive terms and I don't think I like them either, so I certainly understand the problem.

I would say use "actor's enqueuer" and "caller's enqueuer", but if you want more organized feedback, I would say that what people suggest should be collected and then voted on in a poll (including the existing terms and possibly also the queue/address/mailbox derivations from the other thread).

* The queue is no longer a "caller to actor" queue if you're using it to send messages from somewhere else, so I don't really think the relationship is relevant, but I understand the reasoning behind it.

[kegghead]

From a philosophical (that is almost irrelevant) standpoint I don't like the "Caller-To-Actor" nomenclature because nothing says that enqueuer has to be explicitly used by only the caller. Though I firmly believe a component should never expose it's actors' enqueuers directly to the outside world (because of the ability for a malicious or poorly designed message to swap out your actor at will, see @lava) the framework doesn't prevent as much, so I think it's presumptuous to assume that the enqueuer will only ever be used by the caller.

The "Caller's Enqueuer" name runs into the same dilema. On second thought I don't think I mind the "Caller's Enqueuer" name because it should be a one-to-one channel which the Actor will notify when appropriate, it never will be a one-to-many relationship.

I do like "Actor's Enqueuer" though because it perfectly describes the use and target.

[drjdpowell]

kegghead wrote:

From a philosophical (that is almost irrelevant) standpoint I don't like the "Caller-To-Actor" nomenclature because nothing says that enqueuer has to be explicitly used by only the caller. Though I firmly believe a component should never expose it's actors' enqueuers directly to the outside world (because of the ability for a malicious or poorly designed message to swap out your actor at will, see @lava) the framework doesn't prevent as much, so I think it's presumptuous to assume that the enqueuer will only ever be used by the caller.

And don't forget the "inside" world; any subActor launched by the Actor will be sending messages via the "Caller-to-Actor" enqueuer.

[KuGr]

I would prefer the "Actor-to-Caller Enqueuer" terminal to be named  "Caller Enqueuer" or perhaps "Caller's Enqueuer" as it provides some consistency with the protected accessor method "Read Caller Enqueuer" in Actor.

And while I am not a fan of the "Caller-To-Actor Enqueuer" terminal  name, changing it to "Actor Enqueuer" or something similar would make me want change the message Last Ack method of "Read Caller-To-Actor.vi" to "Read Actor Enqueuer.vi" to retain that consistency.  I am not sure that changing that method name is likely as it alters deployed code.  The inconsistency could be 'explained away' in documentation I suppose.

Though Actor method "Read Self Enqueuer.vi" could be changed to "Read Actor Enqueuer.vi", I don't have as much of a problem with the different name.

-Kurt

[Daklu]

In my Create MyActor methods I call the caller-to-actor enqueuer an "input queue" and the actor-to-caller enqueuer an "output queue."  The input queue is for messages going to that actor, and the output queue is for messages coming from that actor.  There is still some ambiguity that depends on perspective, but it's not nearly as bad (imo) as "send queue" and "receive queue."

For me, the main problem with "send queue" is that the word "send" is a verb most often associated with something departing, not something arriving.  So when I'm outside an actor, "send queue" terminology makes sense, but when I'm inside an actor, all of a sudden I'm receiving messages on the send queue and sending them on the receive queue.  It required too much mental gymnastics.  Conversely, an actor's "input queue" means the same thing regardless of whether you're inside the actor or outside the actor.

Semantically input/output queue isn't that different from send/receive queue, but it made all the difference in the world for me.

[tst]

Daklu wrote:

In my Create MyActor methods I call the caller-to-actor enqueuer an "input queue" and the actor-to-caller enqueuer an "output queue."

That's conceptually wrong when you're talking about the AF. Each actor only has a single queue, and that's an input queue. What you're calling an output queue is simply the caller's input queue, which in principle the actor doesn't actually need (hence the original discussion about root actors) and which certainly doesn't belong to it.

Of course, if you strictly adhere to a tree structure, then you can sort of squint your eyes and think of that queue as the output queue reporting back to the caller from the actor's perspective, but I don't see any way anyone would go near such naming, as it's quite incorrect on a technical level and it only applies to a single use case in that one spot.

[Daklu]

You are correct that technically there is no such thing as an output queue--strictly speaking every queue is an input queue.  However, depending on one's needs it can still be beneficial to think of the caller's input queue as an output queue, even in the AF.

In my actor hierarchies the higher level actor has specific knowledge of (is statically coupled to) lower level actors, but lower level actors are not statically coupled to higher level actors.  In practice this means the lower level actor defines all the messages it accepts from a higher level actor (input/request messages) and all the messages it sends to a higher level actor (output/status messages).  It's the higher level actor's responsibility to adapt to the interface provided by the lower level actor.  When using input/output messaging semantics input/output queues make perfect sense.  Of course the AF uses command-pattern messaging (which is an input message by nature) so it's a bit more work achieve the level of decoupling where input/output message semantics make sense, but it's absolutely possible to do it without violating AF principles.

----------

It's hard to suggest appropriate names without having a better idea of what direction AQ wants to go with the AF and what kinds of topologies and messaging semantics he tacitly approves.  For a static tree-based topology "caller enqueuer" and the variations suggested are fine imo.  With the introduction of "Launch Root Actor" other topologies will now be possible, though they will lose some of the built-in protections the AF provides.  Someone could launch every actor as new root and assemble them however they want, so maybe "caller" is no longer the best word.  In tree topologies I tend to think of the higher level actor as the "controlling," "managing," or "owning" the lower level actor.

Currently the AF only supports a static message tree--once an actor has been launched there is no ability to change the actor-to-caller enqueuer.  If AQ decides to add a setter method and support dynamic message trees then "caller enqueuer" is less useful, since the actor that launches another actor may not be the actor that is currently managing it.

And to touch on something I've mentioned before, there are different kinds of messages as well.  Control messages cause actors to change states.  Examples could include "Exit," "OpenFile," "StartTest," etc.  Data messages convey information, but don't cause an actor to change state.  My working theory at the moment is an application strongly benefits from maintaining a hierarchical control message tree, but data messages can cut across the tree without much risk.  To put it another way, the control tree is a subset of the complete messaging topology.  The AF assumes the message tree is identical to the control tree, which may or may not be desirable for any given application.  If separating the control tree from the complete message tree is something AQ wants to support, maybe there is other terminology that acknowledges that.

[drjdpowell]

Daklu wrote:

Someone could launch every actor as new root and assemble them however they want, so maybe "caller" is no longer the best word. 

Actually, I almost certainly would do that, replacing the Actor-to-Caller queue with a mix of a publish-subscribe system and messages with attached reply addresses (er, reply enqueuers).  I don't want actors to have unrestriced access to their callers queue.