Add a `DispatchBroadcastingActor`

[leandro-lucarella-frequenz]

What's needed?

We need an actor that is in charge of abstracting the access to the dispatch API for receiving dispatches, and that can act as a local cache for dispatches, so if the connection to the dispatch API is lost other actors can still get whatever contents could be fetched in the past.

Proposed solution

Add a DispatchBroadcastingActor that will poll the dispatch API and save currently active dispatches (start time in the present or future) and broadcast them, so it can reach other actors.

When an actor first subscribe to the dispatch channel, they will get the whole list of active dispatches and then when new dispatches are found in the dispatch API, they will be sent to the channel too.

This could be done in a class or actor, but an actor is preferred because we only need one cache for a whole microgrid location, not one per process/controller.

Use cases

No response

Alternatives and workarounds

No response

Additional context

• Dispatch architecture with diagram.

• We have an internal actor, we can start moving this actor to the SDK or build it from scratch depending on how much will change with the dispatch API client.

[leandro-lucarella-frequenz]

FYI @thomas-nicolai-frequenz @stefan-brus-frequenz @christianparpart @sahas-subramanian-frequenz

[leandro-lucarella-frequenz]

Blocked on:

• Add a dispatch API client #290

[thomas-nicolai-frequenz]

I was wondering if the actor should more be called along the lines of a "dispatch request broadcaster" or "dispatch request router"?

[leandro-lucarella-frequenz]

Hehe, the name discussion for this actor is endless. IMHO "dispatch forwarding" is shorter and still fairly accurate, although any of your suggestions would be equally short if we remove the "request", which IMHO is a bit redundant. "Routing" IMHO is not precise though, as this actor won't decide where to send dispatches, it will send them to all other actors (if it would decide, "I will send X dispatch only to Y actor" then routing would be OK, but in this case I think it should be "forwarding" or "broadcasting", but if you will also be able to query the actor explicitly saying "give me all currently active dispatches" then it does more than just forwarding/broadcasting.

I also thought about "dispatch caching" as from what I understand from the meeting it's just caching the dispatch API so it is available off-line. There would be no functionality loss if this actor didn't exist and actors would query the dispatch API directly (except they would need to deal with being off-line themselves). So having a local cache seems to be the main goal of this actor.

To be honest, I don't know, we should flip a coin and stick with whatever we get :D

[thomas-nicolai-frequenz]

DispatchBroadcastingActor vs. DispatchForwardingActor, I tend to say I like the first one a little more. The caching is more a means to an end to me tbh. I'd vote for the first one. It makes it more explizit about also what it does.

[leandro-lucarella-frequenz]

OK, renamed to DispatchBroadcastingActor.