[Standards] Re: Proposed XMPP Extension: Jingle Remote Control

Le mardi 14 mai 2024, 17:34:45 UTC+2 Daniel Gultsch a écrit : Hello, Sorry for the late reply; I was on vacation. Thank you for your feedback. I'll address your concerns below: There are many benefits to using CBOR: - It is smaller. While individual pieces of data may be tiny, the cumulative amount is significant, and efficiency is crucial. - Segmentation is inherent in CBOR, so you always know if you have all the data. This is beneficial for optimization and security. - Encoding and decoding CBOR are much more efficient, essential for quick and efficient data processing, especially by low-resource devices (like Arduinos). The whole point of Jingle applications is to specify the protocol. I'm not sure where the problem lies here. Using server-based <message> would be highly inefficient. Why send gamepad data to the server, incurring delays and extra processing, when you can send it directly from your local network? Add e2ee concerns (e.g. OMEMO override in size and processing), and you're wasting a lot of resources. Regarding direct XML streams, CBOR is still more efficient. Additionally, the protocol is based on web APIs, and CBOR provides a direct mapping. Using XML would require reinventing the wheel. The protocol described here is for input sending and potentially other features like clipboard sharing, gamepad, and haptic feedback. In combination with existing specifications, one use case can be remote desktop. The goal is to reuse existing XMPP building blocks to simplify implementation. That’s what XMPP is for: coordinating specifications. We already have an A/V transmission protocol. With WebRTC, it's extremely efficient regarding latency and bandwidth. It’s suitable for remote desktop streaming, including robust network traversal mechanisms. Regarding mouse cursor hiding, I've considered it and will include it in a future version (my implementation does hide the cursor). And, as mentioned, the protocol comes from Web APIs because they are simple, well-documented, and provides a well-thought-out abstraction of the hardware. Low latency is crucial for inputs, especially for devices like gamepads, touchpads, and mice. Even with keyboards, low latency can be important, for instance, when playing a game. I've used this protocol to utilize my phone as a graphics tablet for MyPaint on my desktop: lot of events, and low latency very much needed. For very low-resource IoT devices, a "parent" device could handle the XMPP work, with the stream established directly with the IoT device. I see XMPP in IoT as a “router” device managing XMPP and communicating with other devices on the local network using other protocols. But XMPP itself could certainly be used directly in many modern devices, potentially with some optimizations. I hope that I have answered all your feedback. Regards, Goffi