Design question on sink classes and emits about bumble HOT 4 CLOSED

Do you mean device<->host uses Pyee but host<->transport uses sink method, and the inconsistency is somehow weird?

from bumble.

Yes exactly.
Is there a reason not to be consistent throughout the stack?
It makes it harder to trace through the code.
Also that the flow goes via Device to the Gatt server and not directly through the layers confused me a bit.
So flow from usb to gatt server seems complex to decypher, so I presumed there must be a reason to use different techniques.
The pdf is my attempt to follow the flow through the stack:
https://github.com/paulhamsh/PicoWBLEMidiTest/blob/331bc01f89aaa8e90e6cb288c27a4b7a2d7f2a0a/Bumble%20Overview.pdf

I am thinking using coroutines throughout might be cool.

from bumble.

The reason there are different ways layers call each other is because initially the code base didn't use pyee, that came later. Not everything has been updated to use pyee, so there are still direct calls to on_xxx methods, or sink functions (very lightweight for cases where the emitter holds directly a reference to a function, rather than an object on which it calls one or more methods by name).
For the transport library, it will likely remain this way, as the source/sink model is close to the way asyncio works in general with transports and protocols (ex: data_receveived methods being called), and is quite a bit lighter than the generic multi-listener model of pyee. For other layers, like gatt, it is possible that we'll end up updating to pyee events at some point.

from bumble.

Ah - thank you for explaining. That really helps

from bumble.