Tooted some showerthoughts on actors on the fedi this morning, in response to @hrefna. I don’t know how useful this is in practice, but it strikes me that in actor-based applications the top-level actor represents the entire application e.g. a full-blown webshop or banking app.
On the Fediverse our Person actors are like top-level actor systems. A Mastodon actor represents the full microblogging app, a single “email” address that exposes the full “API” to the world for integration. That’s a complex actor right there.
In the sketch I drew yesterday on the Social Web and App Free Computing topic, when I as a person am interacting witht the Recipe, then that involves a long-running task with the remote RecipeService that offered me this dynamic view. The business logic is owned by that service, and not by Mastodon that only displays it in a timeline.
So I shouldn’t exchange Recipe activities with the Mastodon actor, but with RecipeService in the context of both the Mastodon actor and the particular Recipe I want to cook. The top-level Person actor in an actor model would spin up a child actor hierarchy dynamically, delegating all this processing.
If some person provides an Ingredient for the Recipe and that information is exchanged between (remote or local, but network-transparent) child actors, then these don’t need intricate Inboxes. I can only find information on our particular prior exchanges/transactions.
And after the Activity has been processed by all actors involved, the child actors will be killed, they no longer need to exist. And the msg exchanges related to them can be discarded. Only higher level actors remain. If I want to have further interaction with the Recipe then new actor hierarchies are spun up.
Here’s text quoted from my showerthought toots:
We think of actor comms on fedi to be mostly Person-to-Person. That’s like top-level Akka actor systems. In a typical actor model millions of actors may exist in intricate hierarchies spun up as biz-logic processing required.
In that analogy a remote Person actor (or child actor thereof) would receive msg of dynamically created child actor that represents the context/logic of one particular exchange. And inbox represent the prior state exchange.
PersonActor (actor system): “I interact on ActivityX to PersonY”. Instantiates ActivityXActor, delegates task, moves on doing other stuff.
ActivityXActor: “Let’s do some processing. Done. Oh, PersonY is remote”. Instantiates SendMessageActor, delegates task, waits.
SendMessageActor federates processing result to PersonY, receives response. Hands back result to ActivityXActor. End-of-life, stops executing.
Etcetera.
In a typical actor model you get something like network-transparent ActorRefs. The processing of the business logic weaves itself into an intricate processing tree of child actors either locally or remotely. Each actor only has tiny amount of knowledge about the world it lives, is purely focused on its own task.
The top of the hierarchy is where is where humans consume the overview.The top of the tree represents some high-level abstraction. What humans experience is the aggregate of all side-effects created by the actor hierarchy as it operates.Map this dynamic behavior to AS/AP just as the transport protocol and each actor is dedicated, focused.