Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: "Rémy Dernat" <>
To:,Fabrice Rouillier
	<>,Juliusz Chroboczek <>
Subject: [Galene] Re: Galène management interface
Date: Sat, 24 Apr 2021 08:43:38 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 3339 bytes --]


I agree with Fabrice.

Considering the second option (having the admin interface embedded with galene), it would ensure code compatibility between admin webui and the core of galene itself, even between upgrades.

If it is maintained as a plugin *compatible* system, that is also fine to me. It just needs to be compatible even after an upgrade.


Best regards,

Le 24 avril 2021 07:49:15 GMT+02:00, Fabrice Rouillier <> a écrit :
>Hi Juliusz
>In terms of usage, having a sophisticated administration interface
>allows to delegate many tasks to privileged users and is thus an added
>value when using the software collectively.
>For a more personal use or if the number of privileged users stays low,
>the current situation looks fine since it is light.
>I guess that Galene is a fantastic software for a « personal »  use 
>(teaching, conferences with a low number of webcams ) and thus it does
>not seem to be a problem in that case to have a rudimentary interface.
>So one then compare   1 privileged user = 1 galene server  with
>rudimentary administration interface  vs   1 unique server with a
>sophisticated administration interface.
>The first situation lead to some other problems such as  having
>different ports opened for different servers .
>What would be the additional effort in having both (for example a
>choice à compile time) ?
>Fabrice Rouillier
>Bureau virtuel : https://www.rouillier
>> Le 23 avr. 2021 à 18:31, Juliusz Chroboczek <> a écrit :
>> Dear all,
>> There's been a submission for a management interface at
>> The main issue right now is whether this should be merged into the
>> repository.  My personal opinion right now (but I might still change
>> mind) is that I'd like to see it in a separate repository (and Go
>> that depends on Galène.  I've already started exporting some Galène
>> internals in order to avoid code duplication.
>> There are good reasons to keep the interface separate:
>> 1. Galène is intended to be easy to integrate into an existing
>>   (imagine adding videoconferencing functionality to a cat video
>forum or
>>   an e-learning platform).  For embedding, it would probably be
>better to
>>   provide the right hooks for an external interface rather than
>>   a complete management interface.
>> 2. People's opinions on management interfaces are likly to be
>>   and therefore it would be good to not bind too closely Galène with
>>   a single management interface.
>> There are also some reasons to merge the two:
>> I. Having a single repository will make it easier to install both at
>>   same time.
>> II. Having a canonical management interface integrated with Galène
>>    reduce user confusion.
>> I'd like to hear people's opinions on the subject.
>> -- Juliusz
>> _______________________________________________
>> Galene mailing list --
>> To unsubscribe send an email to

[-- Attachment #2: Type: text/html, Size: 7589 bytes --]

      reply	other threads:[~2021-04-24  6:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-23 16:31 [Galene] " Juliusz Chroboczek
2021-04-23 17:48 ` [Galene] " ibu ☉ radempa
2021-04-23 20:44 ` Toke Høiland-Jørgensen
2021-04-24  5:49 ` Fabrice Rouillier
2021-04-24  6:43   ` Rémy Dernat [this message]

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='[Galene] Re: Galène management interface' \

* 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