On 5/15/24 20:35, Marvin W wrote:
Sure, RFB does specify screen content transfer, but for the usecases where there is no screen content RFB can also be used exclusively for input, by setting screen size to 0x0. I'm also not set on RFB, e.g. SPICE might also be a good option as well. I'm just saying that prior art in this area might be worth considering, because, realistically, the proposed protocol is mostly for use as a remote desktop where screen content is transferred. For such a usecase, using a protocol like RFB would provide significant performance improvements (starting at simple things like local cursor rendering that allow for lag free cursor movement) over regular video encoders.
When the intent is to not use this for remote desktop usecases, but any other remote control usecases, the strict requirement to Jingle seems even less useful, as single or few key press usecases seem very reasonable to me when remote controlling headless IoT devices - and for just a few key presses, the overhead of setting up a Jingle session would be unreasonable. 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. And I bet as an IoT device developer you also want to avoid the overhead of a Jingle+WebRTC stack if you can.
Marvin
Yeah probably as is the scope it too broad. MSavoritias
On Wed, 2024-05-15 at 19:11 +0300, MSavoritias wrote:
On 5/15/24 18:48, Marvin W wrote:
Hi,
I also am not sure why to do this custom-CBOR-via-Jingle approach. - I don't see a good reason to use CBOR instead of JSON or XML. We're just adding another object encoding scheme to the protocol suite without any obvious reason. - 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. - 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.
Marvin Good points. But from what I read RFB is not the same way as what is proposed here.
The XEP as is defines a protocol that can send input to any target without needing graphical interface or video calls.
It even says it allows an xmpp client to work as a keyboard for something else for example.
> to use remotely or simulate input devices for another device that may lack them (e.g., single-board computers or IoT devices), and it establishes a framework that can be extended to share data (e.g., clipboard content).
read the RFC of RFB that can't be done with that.
see also in the design goals:
> Work between devices of different screen sizes, or even if a device has no screen at all.
MSavoritias
On Tue, 2024-05-14 at 21:08 -0500, Stephen Paul Weber wrote:
URL: https://xmpp.org/extensions/inbox/remote-control.html I'm unclear on the benefits of this CBOR-over-Jingle approach vs a 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.
If something over Jingle *is* desired, I'm a bit uncomfortable with specifying bespoke binary protocols in XEPs. Jingle can of course be used to send any data of any protocol and so any existing or future remote- control protocol can be used over Jingle. Do we really need something XMPP- specific for this purpose?
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org