feat: add LXMF type definitions#21
Conversation
|
Question for attermann or the broader community: Would we want lxmf features in the microreticulum repo? or should it mirror the python and be a different repo? (and if so, then who will make that repo?) I'm working on LXMF with microreticulum for my rDeck and the LXMF logic is mixed in with the chat application layer, but I could go either way honestly. |
Atterman asked if I could submit a PR for the (working but not stress tested) LXMF implementation I'd made for my (functional but unstable) t-deck firmware. I personally lean towards a separate package/library at the very least, but I do not have a background in C++ and thus am not familiar with industry norms for repo+package/library alignment. Either way, it's not a position I feel strongly about. Whatever makes it easier to adopt and use. |
|
I'm still on the fence myself. I want to keep hardware-specific code out of the main microReticulum codebase for sure, but LXMF doesn't fall under that category. Hosting it in a separate repo adds more maintenance overhead, but does keep things cleaner. Give me a bit to review your PR @torlando-tech and I'll get back to you. |
Add type definitions for LXMF.
This was originally written by Claude Opus 4.5. I went through to review manually against the Python source code. The only difference I noticed is phrasing in the comments/docstrings.
I have not double checked that all of the types are correctly sized, but did spot check TICKET_INTERVAL requires 17 bits at least.
If you'd prefer larger PRs over numerous small ones, let me know and I will hold off until I have reviewed everything in my branch.