Le lundi 20 mai 2024, 17:35:13 UTC+2 Stephen Paul Weber a écrit : > >- 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?
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? > > >> 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. > > 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). > > >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. 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? > > >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. 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
