From: Jeroen van Veen <jvanveen@protonmail.com> To: "galene@lists.galene.org" <galene@lists.galene.org>, Juliusz Chroboczek <jch@irif.fr> Subject: [Galene] Fw: Re: Versioning the Galene protocol Date: Thu, 14 Jul 2022 05:41:59 +0000 [thread overview] Message-ID: <g_G1Ywaja0ec0riVM3lvvv8eoc4xShNFAREY5d5Doov1P6jr1DAU-ipWjg0n2xPme1Yku8rgAwWpfq4Kc9I6jgp6VfVO1X_WxZKUoKLI2KA=@protonmail.com> (raw) In-Reply-To: <j_Wwm3jCn8dC_JljNxEa71isIylRHrqby88tFFV1kOsZFwpGXDISjia2xXfzbHTqerRny3HSZhIejXxcRkbA6fhizxxs8ALpEzrkEsPQJDA=@protonmail.com> Hi Juliusz, > 2. The protocol starts with an exchange of 'handshake' messages. I'm > going to add a field 'version' to the handshake messages, and if the > versions don't match, the connection fails. Sounds good! Additionally, it may be useful to have the protocol.js as a npm package in the Galene repo with its own releases on npm. This would make it easier for external Javascript projects to work with the protocol library. It would add some complexity for Galene's own client, but an additional bundle step may not even be necessary when using es-modules. The current flow to use an updated protocol.js is to copy-paste it from the Galene repo into its own file locally, and then add an export to expose the ServerConnection & Stream. Easy to do, but having a library with its own semver may make it easier to communicate major/minor/patch protocol changes. > Since the client sends it handshake first, this means that the client > will need to commit to a single version, while the server will be able > to adapt its version depending on what was announced by the client. An > alternative would be to allow the client to announce a list of versions > that it supports -- is that useful? Why support multiple versions of the same protocol? Wouldn't that only complicate things at the Galene side? I don't mind personally to stick to a version of the protocol, that was made to work with that particular version of Galene. > 3. If it is useful, we may add an "extensions" field to the handshake > message, in order to allow a peer to announce that it supports > extensions to the protocol, for example new group actions. > > Other than the versioning, I have only one change to make to the protocol > right now: I'm planning to require that the client request explicitly that > it is interested in chat messages. (Currently, the client needs to > actively request media streams, but it has no way to state that it is not > interested in chat messages.) Would that be to be able to subscribe to certain kind of messages? (e.g. chat) Otherwise, I don't understand the use for it. Could you ellaborate? Would it be a problem to just be able to use newly added group actions in the protocol without explicitly having to mention that it's part of an extension? cheers, Jeroen > ------- Original Message ------- > Op woensdag 13 juli 2022 om 7:16 PM schreef Juliusz Chroboczek jch@irif.fr: > > > > > Hi, > > > > Following Rémi's issues, and since there are a number of third-party > > clients for Galène slowly starty to emerge [1,2,3], I think the time has > > come to add some versioning and extensibility to the Galene protocol. > > > > Now Galene uses three different protocols: > > > > 1. A very simple REST interface, that is used to populate the list of > > public groups and to discover group parameters before connecting. > > > > 2. A WebSocket based protocol, used for chat and audio/video codec > > negotiation. > > > > 3. The whole WebRTC protocol stack, which is used for transmitting audio > > and video. > > > > The protocol that needs versioning is the WebSocket-based protocol, number > > (2) above. It is described here: > > > > https://galene.org/README.PROTOCOL.html#message-syntax > > > > I've given it some thought, and here are my plans. Please let me know if > > you think I'm missing something. > > > > 1. I'm going to ignore the built-in protocol negotiation of the WebSocket > > transport, since I don't feel that version negotiation should be done > > at this layer. > > > > 2. The protocol starts with an exchange of 'handshake' messages. I'm > > going to add a field 'version' to the handshake messages, and if the > > versions don't match, the connection fails. > > > > Since the client sends it handshake first, this means that the client > > will need to commit to a single version, while the server will be able > > to adapt its version depending on what was announced by the client. An > > alternative would be to allow the client to announce a list of versions > > that it supports -- is that useful? > > > > 3. If it is useful, we may add an "extensions" field to the handshake > > message, in order to allow a peer to announce that it supports > > extensions to the protocol, for example new groupactions. > > > > Other than the versioning, I have only one change to make to the protocol > > right now: I'm planning to require that the client request explicitly that > > it is interested in chat messages. (Currently, the client needs to > > actively request media streams, but it has no way to state that it is not > > interested in chat messages.) > > > > Comments welcome, none of this has been implemented yet, so it's easy to > > change. > > > > [1] https://github.com/garage44/pyrite > > [2] https://github.com/erdnaxe/galene-stream > > [3] https://github.com/igniterealtime/openfire-galene-plugin > > > > -- Juliusz > > _______________________________________________ > > Galene mailing list -- galene@lists.galene.org > > To unsubscribe send an email to galene-leave@lists.galene.org
next prev parent reply other threads:[~2022-07-14 5:42 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-07-13 17:16 [Galene] " Juliusz Chroboczek [not found] ` <j_Wwm3jCn8dC_JljNxEa71isIylRHrqby88tFFV1kOsZFwpGXDISjia2xXfzbHTqerRny3HSZhIejXxcRkbA6fhizxxs8ALpEzrkEsPQJDA=@protonmail.com> 2022-07-14 5:41 ` Jeroen van Veen [this message] 2022-07-14 9:58 ` [Galene] Re: Fw: " Juliusz Chroboczek 2022-07-15 8:40 ` Jeroen van Veen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='g_G1Ywaja0ec0riVM3lvvv8eoc4xShNFAREY5d5Doov1P6jr1DAU-ipWjg0n2xPme1Yku8rgAwWpfq4Kc9I6jgp6VfVO1X_WxZKUoKLI2KA=@protonmail.com' \ --to=jvanveen@protonmail.com \ --cc=galene@lists.galene.org \ --cc=jch@irif.fr \ --subject='[Galene] Fw: Re: Versioning the Galene protocol' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox