Actor Framework limited by not having an Actor Arbiter/Administrator

[alsoACS]

PrimaryKey wrote:

3. Keep track of the messages sent between actors for debugging purposes - this could be turned off when performance needs to be optimized.

This is already available through the Desktop Execution Trace Toolkit.  You just add the conditional disable symbol "AF_Debug_Trace" = TRUE to your project.

[PrimaryKey]

Yeah thanks for that 😄 I gave the class many times but somehow missed that 😛 since I seem to be at a lost position here I will just do it myself. Thanks for the discussions.

[PrimaryKey]

They don't! They fill exactly the same need in different ways. I belove AF is the only good way to do it.

[drjdpowell]

---

@PrimaryKey wrote:

 I also think that DQMH and other frameworks should not exist, simply because AF is made to have everything, be easy, fast and best out of the box. They need to exist only because AF is lacking. 

---

Well, I could ask you why you aren’t using Messenger Library?  I intend it to "have everything, be easy, fast and best out of the box.”  It’s been in the LAVA-CR since 2012, so it’s been around as long as the AF.  What is Messenger Library missing that makes you use one of those other frameworks?

The honest answer is that none of us have the time to really gain deep knowledge of more that one framework.  I follow both AF and DQMH, but have never done more than the most simple example project in either.

[drjdpowell]

---

@PrimaryKey wrote:

You would however be in a situation where the basic implementation is generic and public and you optimize by limiting it. This would be safe when critically important + easy. When I have an option I always go for generic and easy with options for limiting and optimizing instead the other way around.  

---

In Messenger Library, I go for limited but easy to increase scope.   So one must explicitly allow communication, but doing so is easy.  I have “broken the rules” in special cases to allow broadcast communication between arbitrary siblings, for example.  This was very easy to setup (the Caller just acts as a message repeater), but there is a big warning comment in the code to point out the rule breaking.  

---

@PrimaryKey wrote:

I would argue we need to fix that - basic actors for simple tasks like logging and daq, template actors, tools, debugging, graphs, monitors, performance measurements, schedulers, deployers etc.

---

I (looking from the outside) agree with you.  But I can’t tell if that is because I don’t use the AF.  I would say the AF suffers relative to Messenger Library from a lack of more-advanced messaging patterns, like Register-Notify and Scatter-Gather (Messenger Library is called “Messenger Library” because its primary focus is messaging patterns; its “actor” implementation is an optional extra that uses those patterns).  But then I would also say AF must be hard to debug, yet when I posted a special probe that I thought would help AF debugging, no-one who actually uses the AF seemed interested, indicating I just don’t understand the AF very well.

[alsoACS]

---

@PrimaryKey wrote:

I would argue we need to fix that - basic actors for simple tasks like logging and daq, template actors, tools, debugging, graphs, monitors, performance measurements, schedulers, deployers etc. Of course it's not my decision in the end. 

---

One of the strengths of using a common framework is that anyone can write components that run under that framework.  I have written two - Network Endpoints and the State Actor - and published a third - AQs Remote Actor package.  MGI has written several popular ones as well.  Actors are very amenable to being packaged as VIPs, making them drop-dead easy to distribute, and you can get them approved for the LV Tools Network.

You're right, these tools need to be written.  Most are outside the scope of AF itself, but we are all free to write and publish them.  So if there is an actor you really want to see, write it and share it with the community.

[PrimaryKey]

I see tools like these to be part of a framework. Question of definitions.

[AristosQueue (NI)]

I'll talk about Pitor's suggestion in a separate post. It's not bad, but I think it is somewhat flawed still.

What I want to discuss first is whether AF should even have as its goal being so ubiquitous.

> I also think that DQMH and other frameworks should not exist, simply because AF is made to have

> everything, be easy, fast and best out of the box. They need to exist only because AF is lacking. 

I certainly wanted AF to become ubiquitous. when I created the AF, but as time has gone by, I've decided that's a fools' goal. Given what I have learned, I don't think one framework will ever dominate because of the competing and contradictory requirements of various projects and people. There are people who will not accept any framework that requires its users to know objects, period -- AF will never be able to accommodate them. There are people who want open to name lookup to be the default for all actors and any sort of permission systems that allow an actor to limit itself is inherently a bad idea (because in that philosophy, good actors should be designed to assume that they are public) -- AF, even with a permission system, won't be able to accommodate them. And so on.