Le mardi 14 mai 2024, 17:34:45 UTC+2 Daniel Gultsch a écrit : > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Jingle Remote Control > Abstract: > This specification defines a way to remotely control a device using > local peripheral inputs. > > URL: https://xmpp.org/extensions/inbox/remote-control.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > _______________________________________________ > Standards mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
Hello, Sorry for the late reply; I was on vacation. Thank you for your feedback. I'll address your concerns below: > I'm unclear on the benefits of this CBOR-over-Jingle approach vs an XML-based > <message>-based approach? Unlike audio/video this data is tiny and does not > benefit nearly as much from direct transmission or binary packing. 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). > If something over Jingle *is* desired, I'm a bit uncomfortable with > specifying bespoke binary protocols in XEPs. The whole point of Jingle applications is to specify the protocol. I'm not sure where the problem lies here. > - If we define a protocol for remote control, I would prefer this to be > a <message>-based protocol that can be used either using a traditional > XMPP connection or via XEP-0247 Jingle XML Streams. 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. > - Rather than defining our own protocol for remote control and using > traditional video conferencing tech for screen content transfer, I'd > prefer to reuse something like the RFB protocol (RFC 6143), aka. only > create a spec to define how to use RFB via Jingle. 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. > In fact low latency, the main improvement of > Jingle vs inband, is only really required if you do have more or less > immediate feedback from the receiving device - e.g. when the screen > content is streamed. 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. > And I bet as an IoT device developer you also want > to avoid the overhead of a Jingle+WebRTC stack if you can. 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
