Object handling structure

[Netzvamp]

With that in mind: #58

My way of handling events is to hand them down until they are in the correct object:

session --> channel --> result

Each class holds a dict where the key is the uuid, so lookup is fast. Whenever we send a message we give the message a unique uuid, that we add to the corresponding dict.

What do you think about that principle?

[Otoru]

Can you explain a practical use case to help me understand this?

[Netzvamp]

I've compared the implementation in genesis/channel.py (current) vs genesis/channels/ (proposed). The decision comes down to two critical factors: Scalability and Architectural Integrity.

1. Scalability: O(1) Routing vs. O(N) Broadcasting
Currently, the Protocol uses an Observer Pattern where every channel listens to the global event stream.

• The Overhead: If you have 50 active channels on one connection, every single event triggers iteration through all 50 listeners. 49 of them wake up, check if event.uuid != self.uuid, and sleep again. This is $O(N)$ overhead per packet.
• The Solution: The proposed Session acts as a Hash Router. It performs an $O(1)$ lookup on the Unique-ID and dispatches the event only to the relevant Channel. The other 49 are never touched.

2. Architectural Integrity: Separation of Concerns
The current design mixes "Transport Logic" (receiving events) with "Domain Logic" (handling call state) by having Channels subscribe directly to the Protocol.

• The Problem: The Session (or Protocol) is currently just a pass-through pipe. It doesn't actually manage the calls it carries. This makes multi-leg scenarios (bridging, transfers) fragile because there is no central authority knowing "these two channels belong to this session."
• The Advantage: My structure enforces strict Containment.
  • Session: Responsible strictly for I/O and Routing. It "owns" the Channels.
  • Channel: Responsible strictly for State and Business Logic. It is isolated from the noise of the connection.
  • Result: Responsible strictly for Async Control Flow.
    This creates a clean hierarchy (Connection -> Leg -> Transaction) that mirrors the actual FreeSWITCH domain model, rather than a flat list of event listeners.

Practical Example:
Imagine an outbound dialer with 100 parallel calls on a single connection.

• Current Code: 100 completion events trigger 10,000 filtering checks ($100 \times 100$).
• New Code: 100 completion events trigger exactly 100 dispatch actions.

This shift from "filtering noise" to "routing signals" is essential for a robust, production-grade library.

Since i'm lazy AI helped me with that 😉

[Otoru]

That sounds good to me, but I'm not going to simply drift through the entire structure, especially the high-level APIs of the project. I'd really like to see something evolving in the direction you described, but with atomic changes that don't completely break compatibility with the existing API.

[Netzvamp]

That's understandable und why i've implemented it into the channels submodule with the latest PR. It's hard to just implement some parts of it and it would break existing API on some point sooner or later. That why a seperate API was so attractive to me: We don't touch existing stuff but can implement a complete structure.
How could we make a event handling change in small atomic steps? Do you have a structure in mind that would allow that?

[Otoru]

I think we have minor changes beyond that which we've already agreed on how to handle in other discussions, and we can even change the current logic, such as manually writing all the events related to that UUID when creating a session and then filtering at the Python level. Making atomic and incremental changes is the challenge of maintaining any large software in production, and here we're not going to have anything different from that.

[Otoru]

I tackled the O(1) routing problem in PR #63. Would love your feedback @Netzvamp!

[Otoru]

I'm going to end this discussion due to lack of interaction, since the PR has moved to the main branch

[Netzvamp]

Sorry, i had to tackle another urgent project, i'll take a deeper look next week.