From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=webweaving.org (client-ip=148.251.234.232; helo=weser.webweaving.org; envelope-from=dirkx@webweaving.org; receiver=) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; unprotected) header.d=webweaving.org header.i=@webweaving.org header.a=rsa-sha256 header.s=shared header.b=iDJ+El/t Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) by mail.toke.dk (Postfix) with ESMTPS id 31C41A54C76 for ; Tue, 13 Feb 2024 14:59:45 +0100 (CET) Received: from smtpclient.apple (83-85-39-103.cable.dynamic.v4.ziggo.nl [83.85.39.103]) (authenticated bits=0) by weser.webweaving.org (8.17.1/8.17.1) with ESMTPSA id 41DDtn1P055275 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Feb 2024 14:55:52 +0100 (CET) (envelope-from dirkx@webweaving.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=webweaving.org; s=shared; t=1707832557; bh=fJKEPO4C8wTm+qpvCo4qf8XdSz1Bn3Byf6/Xe21BTD0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=iDJ+El/tlgTQmE1uXdClbHOnFJ9tjP2VJBdf/7aIYq2jYq8i3QD2zAcp2O5nL8d88 ieARC0fqZorPi2TFqhLvproHvki3Th77nQpnW7BUP8ZXGo4BzRt2GEFhp0y5jI1lFS 3IBpwgq5SaIMoPTELPmQanISwsKO2/R64NeEqcY0= X-Authentication-Warning: weser.webweaving.org: Host 83-85-39-103.cable.dynamic.v4.ziggo.nl [83.85.39.103] claimed to be smtpclient.apple Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) From: Dirk-Willem van Gulik In-Reply-To: <87o7ckecam.wl-jch@irif.fr> Date: Tue, 13 Feb 2024 14:55:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C5BACF6-2E9E-45E2-A3CB-619BB60DE670@webweaving.org> <87o7ckecam.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (weser.webweaving.org [148.251.234.232]); Tue, 13 Feb 2024 14:55:57 +0100 (CET) Message-ID-Hash: KX5CLGTRBOJISOIXZSSZQYA6KJQ6ZWMW X-Message-ID-Hash: KX5CLGTRBOJISOIXZSSZQYA6KJQ6ZWMW X-MailFrom: dirkx@webweaving.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: galene@lists.galene.org X-Mailman-Version: 3.3.9 Precedence: list Subject: [Galene] Re: Virtual groups v.s. new API branch List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 13 Feb 2024, at 14:14, Juliusz Chroboczek 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. >=20 > Right, makes sense. >=20 >> 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). >=20 > 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. >=20 >> Now I just noticed this https://github.com/jech/galene/tree/api. Fair = to >> assume that this will be the `proper' way ? >=20 > That's the plan, but it's still open to discussion. In order to = create > a group, you'll do: >=20 > PUT /galene-api/group/groupname/ HTTP/1.1 > If-None-Match: * > Content-Type: application/json >=20 > 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). >=20 > 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.=20 But that extra information is actually more `push' information; it does = not need to be pulled.=20 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=