Hi Goffi, Before going on your specific points, I'd like to make clear that I'm all in favor of this happening and this vote was very uneasy to me, because I also don't want to discourage you. I still do think that this XEP is bad for many reasons, some of which I apparently fail to get across, so I'll try to make it more explicit and to the point in this email.
On Mon, 2024-05-27 at 10:54 +0200, Goffi wrote: > For now, the biggest criticism I've seen is that this protocol > specification > is… specifying a protocol (which again is required by XEP-0166 for > Jingle > applications). One major criticism is that it specifies TWO protocols. The first protocol (sections §5-7 of your proposal), which clearly belongs into the XSF, is how to use Jingle to signal a remote desktop session. As you rightly point out a Jingle application format (as per XEP-0166 §12.1) must DEFINE how the "media data" is sent. However, it doesn't need to SPECIFY the media data format. E.g. XEP-0167 defines you should use RTP packets as specified in RFC3550. The second protocol (sections §8-9) is the one that is the media data to send via the Jingle session. However that protocol is largely independent of Jingle or anything else and could be and IMO better would be specified entirely independent of that. When I said that you should consider to evaluate if a XEP is the right place to specify such a protocol, I was only referring to this part: As it stands right now, this second protocol could easily be used independent of XMPP and Jingle. I would thus see this protocol more as an RFC. > On the other hand, this introduces complexity by itself (now the > payload can > go through two different ways) Under the assumption that all remote control signals are sent using <message> and it is up to the receiving client to decide to accept or error them, there is no additional complexity introduced, by adding the possibility of a different transport path. In fact, you wouldn't even need to specify which transport path to use, you specify the stanzas to be sent to do remote control (to maintain remote control session and for input events). The fact that one decides to send those via Jingle XML streams and others use serverless messaging doesn't need to be specified, it's exactly the same stanzas being sent in both cases. > Jingle is a major stack of XMPP, and it should be implemented in any > advanced > client according to IM compliance suites. Except that many clients are not meant to be advanced IM clients. I wouldn't expect a remote desktop application to strictly also be an advanced IM client. Looking at the feature set we require from advanced IM clients, I'm pretty sure most existing remote desktop apps do not qualify as advanced IM client (probably not even core im client, because group chats are definitely not common for remote desktop apps). Again, You seem to be coming from the position that a client implementing this is already a very feature rich and advanced client like yours, but this assumption comes with a huge amount of restrictions. > Maybe I got it wrong, but for me, the job of the Council is to keep > technical > stuff on track by ensuring that advancements in XEP statuses are done > in order > (i.e., X independent implementations, Y feedbacks, etc. as stated in > relevant > XEPs), and vetoing things that are really unacceptable (e.g., > copyright > issues, something totally irrelevant, offensive content, etc.). And > it's the > role of the larger community on standard@ to work on technical stuff, > side > cases, ease of implementation, and optimization. This does not match my understanding of Council work. I see Council as clearly a technical position, not a mostly organization position. In fact, some of the tasks you listed are clearly on the Editor side and shouldn't even reach Council (e.g. copyright issues and offensive content). > I realize that there isn't a real definition of what should be an > "acceptable" > proto-XEP; maybe this should be specified? Because I've seen proto- > XEPs refused > by some Councils then accepted by others, and this seems quite > arbitrary to > me. We do have a Council of multiple members, because Council work is not solely fact-based, but also involves individual opinions of its members. If approving a XEP for publication was exactly following a checklist of well-defined points, we wouldn't need the Council for it. > So we're just talking about Jingle, and this can be implemented on > any > platform I do agree that Jingle can likely be implemented on any platform, but it might be that you can only do so using Jingle IBB (e.g. because your network controller can only maintain a single TCP connection), in which case using Jingle is really not an improvement. > That's incorrect. Despite its name, you can actually only use the > Remote > Desktop portal to send input; the Screen Sharing part is entirely > optional > (and must be explicitly requested). I'm pretty sure you can't send absolute pointing events (via NotifyPointerMotionAbsolute like for a drawing tablet) or touch motion events (via NotifyTouchMotion) using the RemoteDesktop portal without also opening a screen cast, because the PipeWire stream node of the screen cast is a parameter for those APIs. So while some events can be sent without the Screen Sharing, it's not entirely optional. > As I've said in my previous message, the wheel device, while often > associated > with mice, can also be independent. The RemoteDesktop portal clearly ties it to the pointer device, it's not only that the name is NotifyPointerAxis but you also must request a POINTER device in the session (i.e. only requesting a KEYBOARD and TOUCHSCREEN device does not allow you to use the API for scrolling). > We have already EXI (XEP-0322) for that (I don't know how it compares > to CBOR > though). I know we have EXI and I know basically nobody implements it. It's very complex, has a lot of features and for best results requires to agree on a common set of XML schemas. Having something else than EXI that is easier to implement really might be a good idea, because I doubt EXI is going to ever be successful. -- So as a summary, for me the deal breaker really is the two protocols in one XEP, one of which is not really an XMPP protocol. If you do like the two protocols that you built - after all, you have implementation experience that I entirely lack, so it may be that all my concerns are invalid and I'm happy to have that in Experimental - I just feel that the second one should best not be at the XSF and if there's really no better place, make it at least a separate XEP. Marvin PS: I also firmly believe that splitting those two protocols will make the protocol design better, because you can't (or at least are less likely to) have weird interaction between unrelated protocols anymore. _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
