Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <jch@irif.fr>
To: Jeroen van Veen <jvanveen@protonmail.com>
Cc: "galene@lists.galene.org" <galene@lists.galene.org>
Subject: [Galene] Re: Fw: Re: Versioning the Galene protocol
Date: Thu, 14 Jul 2022 11:58:33 +0200	[thread overview]
Message-ID: <87ilo08186.wl-jch@irif.fr> (raw)
In-Reply-To: <g_G1Ywaja0ec0riVM3lvvv8eoc4xShNFAREY5d5Doov1P6jr1DAU-ipWjg0n2xPme1Yku8rgAwWpfq4Kc9I6jgp6VfVO1X_WxZKUoKLI2KA=@protonmail.com>

> 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.

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 screenshare.)

> Would that be to be able to subscribe to certain kind of messages? (e.g. chat)

In order to join a group, you currently do:

    C->S: join(groupname)
    S->C: joined(groupname)
    S->C: chathistory, chathistory, chathistory
    C->S: request(audio, video)

There is no way to avoid receiving the chat history, and there's no way to
avoid receiving chat messages.  The proposed protocol is

    C->S: join(groupname)
    S->C: joined(groupname)
    C->S: request(audio, video, chat)
    S->C: chathistory, chathistory, chathistory

Unless you explicitly request chat, you're not going to get the burst of
chathistory messages, and you're not going to get any chat messages.

> 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?

If you send a groupaction that the server doesn't know about, you'll
receive an error message.  It would be useful to be able to avoid exposing
a group action in the UI if the server doesn't support it, and that's what
the extension mechanism could be useful for.  Whether this will prove
necessary will depend on whether useful native clients surface.

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 (streamed
XML, giggle).

-- Juliusz

  reply	other threads:[~2022-07-14  9:58 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   ` [Galene] Fw: " Jeroen van Veen
2022-07-14  9:58     ` Juliusz Chroboczek [this message]
2022-07-15  8:40       ` [Galene] " 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=87ilo08186.wl-jch@irif.fr \
    --to=jch@irif.fr \
    --cc=galene@lists.galene.org \
    --cc=jvanveen@protonmail.com \
    --subject='[Galene] Re: 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