Default Actors Methods

[sleipnir]

I propose creating default methods for actors.

My idea is that all actors automatically have methods to get values from the actor's state. That way users who want to implement methods just to get and/or set the state value don't need to code such methods, they would already exist by default.
Obviously this option could be optional and the definition of such methods could exist or not based on configuration so that this feature does not need to be changed in the SDKs.

The method names could be get_state and if the user is called by GetState or getState the system should understand these names as valid as well.

I think it's dangerous to provide a method to set an actor's state, but this might be another option if the user really wants such a method.

[sleipnir]

A benefit that I didn't mention in the description because it seems obvious to me, but maybe it's not that much and that's why I'll talk about it now, is that when defining a default method that returns only the current state of the actor, so this actor doesn't need to call any Host Function, because in this case, there is no computation involved in the data, just getting its value. This in turn avoids a round trip call from the network to the host function and makes this method allied with the fact that the actor's state is always retrieved, except at initialization, directly from fast access memory.

[sleipnir]

@eigr/core-team @eigr/contributors wdyt?

[marcellanz]

My idea is that all actors automatically have methods to get values from the actor's state

I try to understand. This is, a method implemented for the Actor in advance, hence a default. This is kind on protocol level as an actor could not access its proxy local state, this way the proxy knows about the semantics of getstate?

[sleipnir]

Yes!

[sleipnir]

Let's say there are proxies A and B, each of these proxies communicate via http with their respective Host Functions.

If the Host Function referring to Proxy A wants to know the current state of Proxy B (and here I will not go into the merits of why it would do such a thing) things would happen as Host Function A invokes the Actor present in Host Function B through your local proxy.
The local proxy, in turn, locates where the actor is and makes a call via Distributed Erlang to Proxy B, which in turn must make a call to Host Function B. Proxy b, however, passes the current state of the requested actor to the Host Function B via HTTP Request on actions endpoint

In other words, Proxy B sends the state to the Host Function, which in turn will return the state to Proxy again. Which will be returned to proxy A which will deliver the information to Host Function A

But if the intention is to only return the state of the Actor then why does Proxy B send this state to Host Function B instead of already returning the state to Proxy A ?

If the user's intention is to just return the value of an actor then we don't need the user to create methods to do just that.

Now if the user wants to perform some computation, or even update its state differently before responding then he can do that by writing any method with a different name