Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
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

  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