Message flow for mediated messages
TelegramSam opened this issue · 3 comments
I'm working on adding the ability for the toolbox to use a mediator for connections to other agents. This ability will extend the types of interactions that the toolbox can have with agents, including mobile agents or agents behind firewalls.
Here is the question: How should we refactor the code to handle messages received through the mediator? Currently, connections are maintained by the connection-specific windows (AgentBase.vue). Using this window presents two problems:
- Messages must be passed from the mediator window to the appropriate connection window. This is likely solvable via the message bus.
- If the mediator window is closed, how is the connection to be maintained?
I think the right answer is for the 'core' toolbox agent to maintain the connection with the mediator. This means that we would need an additional connection (keypair on both sides) for the exclusive use of the mediator. This allows all inbound mediated messages to flow to the 'core' agent (maintained in the AgentList.vue code) to be distributed to the appropriate connection specific windows.
Thoughts on this approach, or better ideas on how to solve the problem?
I'm still getting reacquainted with where things are at right now lol and I'm still thinking about this but a couple of initial thoughts/ramblings.
Messages must be passed from the mediator window to the appropriate connection window. This is likely solvable via the message bus.
As it currently stands, a new message bus is created for each AgentBase, i.e. it's not global. Local message buses were nice at the time since it meant that there was no way for one agent window to receive another agent windows messages on accident but now we're seeing the limitations of that approach. We'll either need a global message bus and some way for agent windows to only get the messages relevant to them (agent windows could add handlers for an event that matches their identifier plus some suffix or something) or a handle to each agent window's message bus with some identifier so we can push messages down the pipe. In both cases, retrieving a handle from a Vue component that I think is outside of each other's parent hierarchies might be a bit tricky. You might have already addressed this in the use_mediator
branch -- I'll have to check that out. Thinking out loud but we might need/it might be cleanest to have a Vue plugin that maintains a global message bus and perhaps that also provides connection establishment and management all in one place. Something that acted a bit more explicitly like an "agent core"?
If the mediator window is closed, how is the connection to be maintained?
I'm not perfectly clear on what you're referring to by "connection maintenance," could you unpack that a little more for me?
This means that we would need an additional connection (keypair on both sides) for the exclusive use of the mediator.
Also a little fuzzy for me. How does the mediator connection differ from the connection already held between the toolbox and an agent that we subsequently request to be a mediator? I might just need to draw some diagrams and stare at them for a moment to see the scenario more clearly.
If the mediator window is closed, how is the connection to be maintained?
A connection to the mediator must be maintained in order to receive messages for the connections that use the mediator. Who is going to keep the socket open if the AgentBase window is closed?
How does the mediator connection differ from the connection already held between the toolbox and an agent that we subsequently request to be a mediator?
If we have two connections to the mediator, it makes it easier to keep the messages split between the mediator directly, and the mediator as inbound message route. From the perspective of the Mediator agent, it will have two independent connections. By opening and maintaining the mediator focused connection from AgentList, the only messages passing over that connection are related to mediation alone, and not any other of the toolbox modules used in AgentBase.
Does that clarify what I meant?
Implemented so I don't believe this is relevant any more.