From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=protonmail.com (client-ip=185.70.43.22; helo=mail-4322.protonmail.ch; envelope-from=jvanveen@protonmail.com; receiver=) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; secure) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=hREr0YZ2 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by mail.toke.dk (Postfix) with ESMTPS id 0042698A9A0 for ; Fri, 15 Jul 2022 10:40:41 +0200 (CEST) Date: Fri, 15 Jul 2022 08:40:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1657874440; x=1658133640; bh=bE1ykeJtsGlVh8mtE9AQl5JnYdSMEfX27uZwOOsSEyY=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=hREr0YZ20rs3exezr9XIFL444jcPhdeUShMJ4rDhP762PUwrRn4QA82/yQBdKo07b 7+7zono2RRignUqgnGTmsrj1g1aRQ8pmZqLEK+mVxDcXOPqIK0/Ejr2ySg6rNooKP5 uFuWGei42q9WptfhiwyavAP8DmDJtHnqnMOGtxJQJeE84MhOYl87mEquoNE74eNr55 ZzAyV+rmXDElEzsjYUwKw0PC5Zo9/yheV/h+tjHQawe44TZ/EEtmrEp14pGwAKjOYG puA5gDB4jdWPmHZTixwErfvUMgNTe+/1mgoljl/+Wq+uNUfhzUuSEM95vq1yGZYT0n B5+55TqVZiqTw== To: Juliusz Chroboczek , "galene@lists.galene.org" From: Jeroen van Veen Message-ID: In-Reply-To: <87ilo08186.wl-jch@irif.fr> References: <87edyp3pc5.wl-jch@irif.fr> <87ilo08186.wl-jch@irif.fr> Feedback-ID: 11782011:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: CHHIEISAW3AYYS2CAPH3HFAJ7KE3WUVV X-Message-ID-Hash: CHHIEISAW3AYYS2CAPH3HFAJ7KE3WUVV X-MailFrom: jvanveen@protonmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.5 Precedence: list Reply-To: Jeroen van Veen Subject: [Galene] Re: Fw: Re: Versioning the Galene protocol List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > > 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 particula= r > > version of Galene. > > If the server cannot support multiple versions, then every change to the > protocol breaks all non-web clients. (There's Galene-stream already, and > I'd really like to see a native client for Android that can do screenshar= e.) The web-version and protocol.js are always in-sync with the current version= of Galene(same repo), Galene-stream has its own protocol.py (https://github.com/erdnaxe/galene-st= ream/blob/main/galene_stream/galene.py), and Pyrite uses a slightly modified protocol.js from the Galene repo. It se= ems useful to be able to keep the protocol implementations in all used languages in sync, by making use of the include= d package managers (pip/npm/...) for the versioning. A new version of Galene with an updated protocol would = then mean updating the protocol implementations in all languages and require the third-parties to update their dependencies= . For instance: https://github.com/matrix-org/matrix-rust-sdk https://github.com/matrix-org/matrix-js-sdk > Ideally, of course, we'd have a single protocol that is used across > multiple servers. Unfortunately, the only standardised videoconferencing > protocols are SIP and Jingle, both of which are somewhat strange (streame= d > XML, giggle). I tried building a SIP conferencing client (https://github.com/garage44/ca1= 1) with Asterisk SFU some years ago. Asterisk itself is quite amazing, but I found SIP (over websockets) persona= lly too complex to deal with signalling. It may be nice to call in a conference with a Cisco phone, but who cares wh= en everyone is using a softphone anyway. A common signalling protocol for SFU's may be nice from a client perspectiv= e, and maybe even for interoperability between SFU's. However, the more interoperability and standardization, the = more it may start to look like SIP (or XMPP).