Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: galene@lists.galene.org
Subject: [Galene] Re: Virtual groups v.s. new API branch
Date: Tue, 13 Feb 2024 14:55:49 +0100	[thread overview]
Message-ID: <D21B4C71-8D23-4CA7-923B-FA628C620C66@webweaving.org> (raw)
In-Reply-To: <87o7ckecam.wl-jch@irif.fr>

On 13 Feb 2024, at 14:14, Juliusz Chroboczek <jch@irif.fr> wrote:

>> to be able to have the /var/db/galene/groups directory (i.e. the -groups
>> cmd line argument) live on a nearby webserver. Basically it just fetches
>> the JSON remote every time.
> 
> Right, makes sense.
> 
>> The main reason for this is to allow the ad-hoc creation of short lived
>> ephemeral rooms that you discover you need, rather than
>> preconfigured. (the jsons are generated on the fly in typical 'cgi-bin'
>> conceptual fashion).
> 
> We use the "allow-subgroups" mechanism for that.  We create a template
> group with "allow-subgroups" set to true, and subgroups are created on the
> fly when a user joins.

That sort of works - but we ended up (perhaps shooting ourselves in the foot) by also configuring auth, presenters, if it could, or could not, get recorded, etc. And we are triggering an `XX  has ben activate'  workflow; with emails if people are late, etc.

> I'm not opposed to hosting group definitions on a remote server, but I'd
> need to understand why the existing mechanism does not meet your use case.
> 
>> Now I just noticed this https://github.com/jech/galene/tree/api. Fair to
>> assume that this will be the `proper' way ?
> 
> That's the plan, but it's still open to discussion.  In order to create
> a group, you'll do:
> 
>    PUT /galene-api/group/groupname/ HTTP/1.1
>    If-None-Match: *
>    Content-Type: application/json
> 
> with the group definition in the body.  Perhaps it's worth adding
> "not-before" and "expires" fields to the group definition, and have groups
> be automatically purged by the server?

Not too worried about that - very easy to do with a DELETE from the configuration service once every night or so.

Once you accept it this is push - fine to keep it push to Ganele.

>> Or is there also a plan for a more 'reactive' mechanism -- i.e. one that
>> does not require a configuration sitting pretty `ahead' of time. We're
>> finding this quite useful (and then lock the room one we're started).
> 
> I'm not opposed, but I'd need to understand why the "allow-subgroups"
> mechanism is not good enough for your use case.


Basically as we configure things ad-hoc differently from group to group & keep redefining groups as we reshuffle the meetings / roles at those meetings. 

But that extra information is actually more `push' information; it does not need to be pulled. 

So conceivably - the API with subgroups may works if you accept that you get no 'callback' from Galene telling you that a new group was created (and we set them to private - so no polling of the public-public.json).

Dw

  reply	other threads:[~2024-02-13 13:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-13  9:20 [Galene] " Dirk-Willem van Gulik
2024-02-13 13:14 ` [Galene] " Juliusz Chroboczek
2024-02-13 13:55   ` Dirk-Willem van Gulik [this message]
2024-02-13 15:15     ` Juliusz Chroboczek
2024-03-03 16:07     ` Juliusz Chroboczek

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=D21B4C71-8D23-4CA7-923B-FA628C620C66@webweaving.org \
    --to=dirkx@webweaving.org \
    --cc=galene@lists.galene.org \
    --cc=jch@irif.fr \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox