20 May
2024
20 May
'24
10:10 p.m.
Le lundi 20 mai 2024, 17:35:13 UTC+2 Stephen Paul Weber a écrit :
What do you mean? It's not like humans are entering the data themselves. Input
devices are used (most of the time) by humans, but that doesn't mean the data
volume is small. With touch devices, you can quickly have several touch points
with diameters, pressure, etc., moving around. You quickly accumulate dozens
of events. Sure, compared to a video stream, that's minor, but it still needs
to be processed quickly and efficiently. Lack of efficiency means latency, which
can be annoying at best and problematic at worst (e.g., in games or precision
tasks).
And in general, when the cost of using an efficient solution is low, why not use
it?
Do we have any examples of a XEP specifying a protocol yet? So far usually
we reuse a protocol, such as RTP.
Well, most XEPs specify protocols.
Regarding Jingle wire protocols, reusing another protocol is essentially
specifying it. And we don't have many Jingle applications so far.
XEP-0166 actually requires specifying how the data is to be sent and received
(https://xmpp.org/extensions/xep-0166.html#conformance-apps).
It's not a generic input-events over CBOR protocol; it's a specification to
control devices via XMPP. This specification is useless without the XMPP and
Jingle stack, and remote desktop use case reuses the existing stack. The wire
format specified here is simple, efficient, and does the job. If using other
standards for wire format is a bad thing, why do we have Socks5, WebRTC, HTTP,
and so on used in XMPP?
It's not a 1:1 mapping of Web API because many data are useless or irrelevant
in this specification. For instance, a Web `MouseEvent` has data such as
`clientX`, `pageY`, and `relatedTarget`, which are not relevant in this case.
Additionally, Web `MouseEvent` indicates key presses during the event, which
are obtained through the `keyboard` device in the specification. Only the
necessary data are kept.
You are right that this should be explained in the specification. If the
protoXEP is accepted, I'll add a section to explain that.
I hope that I have helped to clarify things.
Regards,
Goffi
- It is
smaller. While individual pieces of data may be tiny, the
cumulative amount is significant, and efficiency is crucial.
Why is efficiency crucial when events are being produced at the rate a human
can produce them? 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. Regarding direct XML streams, CBOR is still more
efficient.
No one is saying CBOR is bad in general, but I think if a new
input-events-over-cbor-stream protocol is needed the XSF is not the place to
specify it. Additionally, the protocol is based on web APIs,
and CBOR provides a direct
mapping.
Perhaps this could be called out more? If this is indeed a "direct mapping"
to an existing protocol maybe the concerns about it being bespoke are moot.