From: Juliusz Chroboczek <jch@irif.fr> To: "Michael Ströder" <michael@stroeder.com> Cc: galene@lists.galene.org Subject: [Galene] Re: read groups from API Date: Sun, 03 Jan 2021 02:00:18 +0100 [thread overview] Message-ID: <87eej2hm1p.wl-jch@irif.fr> (raw) In-Reply-To: <23913aea-038e-96de-560e-371972a3c222@stroeder.com> > It would be helpful if groups could be retrieved from a simple web > service which just returns the JSON data. Why does that need to be part of Galène ? Why can't it be a separate service that has access to the filesystem with Galène's configuration files? This way, Galène doesn't need write access to its configuration directory, which is good for security and simplifies deployment (you can run it in a read-only container). > This would make it possible to integrate with other database-backed > management systems so that implementing #11 is not really needed. I fully agree that the management interface should not be part of Galène itself: Galène never writes to disk except if you ask it to record a file, which means it can be run on a read-only filesystem, and that two instances of Galène can use a single configuration directory. The plan is that Galène should automatically pick up any change being made to any of its configuration files; this is not quite the case yet: - changes to group definition files will be picked up the next time a client connects; - changes to the ice-servers.json file will be picked up after two minutes at most, but will only apply to new clients; - changes to the SSL key or to the data/passwd file are not picked up yet, but that is planned in the future. So my opinion is that an administrative interface should not be hacked into Galène -- it should be a separate program that either has write access to the filesystem Galène is running on, or a program running on a different host that propages changes over sftp or rsync. > I'd volunteer to implement an example web service based on Python with > fastapi module. Sure, and don't hesitate to suggest improvements to the configuration file format. In particular, I'm not particularly fond of the current permissions system (op/presenter/other and allow-recording), it doesn't accurately reflect the one used in the protocol (permissions are a bitmap of orthogonal permissions, op/present/record; chat is currently implied, but will become an explicit permission in 0.2.) Please don't expect me to integrate any management interface to the main Galène binary -- the management interface and Galène should ideally only communicate over the shared filesystem. -- Juliusz
next prev parent reply other threads:[~2021-01-03 1:00 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-02 22:33 [Galene] " Michael Ströder 2021-01-03 1:00 ` Juliusz Chroboczek [this message] 2021-01-03 2:12 ` [Galene] " Michael Ströder 2021-01-03 12:31 ` Juliusz Chroboczek 2021-01-03 12:33 ` Michael Ströder
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=87eej2hm1p.wl-jch@irif.fr \ --to=jch@irif.fr \ --cc=galene@lists.galene.org \ --cc=michael@stroeder.com \ --subject='[Galene] Re: read groups from API' \ /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