I have been writing a replacement for Mainsail/Fluidd - ~mronetwo/klipperfrontendnative - Moonraker client for Klipper control - sourcehut git. I’m using C and Nuklear GUI library, so it’s fair to say it’s quite low level compared to the aforementioned projects. It’s been a fun project to work on but there’s one pain point that I really do not enjoy and that’s the JSON RPC based protocol.
I use libcurl to talk to Moonraker so it’s not exactly fair to point my finger at Klipper but the protocol Moonraker uses is a direct consequence of Klippy’s UDS protocol.
I’d like to gauge the interest in adding support for a different protocol on Klippy level, and see if there are some considerations I’m missing.
I feel like the current JSON RPC based protocol is catering to a web based tooling, which seems… a very opinionated choice on that level of the stack. Languages like Python, Go or Javascript have a bit of an easier time to work with JSON objects. I’m not suggesting replacing that protocol. That would be crazy and unproductive. I’m thinking about adding a different protocol.
One protocol that I like is CoAP. I think it covers many needs Klipper has. It has a “native” support for notifications (in CoAP it would be “observes”), for matching request response either through piggybacking (response piggybacking the ACK to request) or matching the response through a token, it has the same methods as HTTP (GET, PUT, etc…). Some request data would be pushed through the CoAP’s payload and that one could use CBOR instead of JSON…? CoAP might be too specific and too high level for a direct Unix Socket, but then on the other hand it’d be easy to expose over the network. One wouldn’t need a intermediary like Moonraker. It would be cool if one could connect an application like mine directly to the host’s socket but also be able do it through the network.
I’m getting ahead of myself with what that new protocol could be.
Let me know what you think. Especially if you think there are reasons something like this wouldn’t get upstreamed.