1.8 KiB
I am trying to extract the protocol-only portion of this BLE Reticulum implementation into a future C++ library callable from Python.
Use /usr/local/src/ble-reticulum/src/ble_symbols_20260516_1429.txt as the master inventory. For every symbol listed in that file, inspect the corresponding source code and classify it as:
[CORE] Protocol logic that may belong in a future C++/Rust library.
[GLUE] Python Reticulum integration that should probably stay Python initially.
[PLATFORM] Linux/BLE/BlueZ/Bleak/bluezero/DBus/GATT/scanning/advertising code.
[TEST] Examples, proof scripts, diagnostics, command-line tools, or test harnesses.
[UNKNOWN] Not enough information to classify safely.
For each symbol, produce a Markdown table with:
- file path
- symbol name
- line number
- tag
- phase-1 C++ candidate: yes/no
- rationale
- important callers, if easily found
- important callees, if easily found
Do not modify files.
At the end, produce:
- A "Phase 1 C++ extraction candidates" list.
- A "Do not port yet" list.
- A short explanation of where the Python/C++ boundary should probably be.
- Any symbols whose classification depends on Reticulum internals.
For information about where reticulum is installed, see /usr/local/src/ble-reticulum/reticulum_info.txt
The main tree is /usr/local/src/ble-reticulum which is pulled from my Forgejo instance. I have created a branch "c++migration" which is the current branch.
Treat ble_dual_node_echo.py as an acceptance test/harness, not as the source of the protocol-core design.
Prefer conservative classification. If a symbol touches RNS.Transport, RNS.Interface, RNS.Link, BleakClient, bluezero, DBus, sockets, threads, or OS-specific objects, do not mark it as phase-1 C++ unless the protocol logic can be cleanly separated from those dependencies.