15 May
2024
15 May
'24
7:35 p.m.
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
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:
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org 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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org