[Galene] Virtual groups v.s. new API branch

[Galene] Virtual groups v.s. new API branch

[Dirk-Willem van Gulik]

I've been using a bit of a hack in 

	group/Update)
		https://github.com/jech/galene/blob/0f53bf037368a2a82a0af30ffd07bf5943b0abb1/group/group.go#L1335

and especially
	group/GetDescription()
		https://github.com/jech/galene/blob/0f53bf037368a2a82a0af30ffd07bf5943b0abb1/group/group.go#L1007

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. 

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

And this http/rev-proxy separation also makes it easier to limit the access galene has; much like the galene-ldap separation/pattern.

Now I just noticed this https://github.com/jech/galene/tree/api. Fair to assume that this will be the `proper' way ? 

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

With kind regards,

Dw

[Galene] Re: Virtual groups v.s. new API branch

[Juliusz Chroboczek]

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

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?

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

-- Juliusz

[Galene] Re: Virtual groups v.s. new API branch

[Dirk-Willem van Gulik]

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

[Galene] Re: Virtual groups v.s. new API branch

[Juliusz Chroboczek]

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

I see.

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

Ok.

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

If you have an auth token, you can check if a group exists simply by doing
HEAD to /galene-api/group/whatever/.  No objection to implementing
a callback, though, if for some reason you cannot poll the server.

-- Juliusz

[Galene] Re: Virtual groups v.s. new API branch

[Juliusz Chroboczek]

>> Perhaps it's worth adding "not-before" and "expires" fields to the
>> group definition, and have groups be automatically purged by the
>> server?

I've just done that.

  https://github.com/jech/galene/commit/de0c42faaf1a72f1e850f64bc720fd2e824f8cb8

You may format ISO 8601 dates from the shell using

    date -Iseconds -d tomorrow

from Go using

    json.Marshal(time.Now().Add(time.Day)

and from Python by doing

    (datetime.datetime.now() + datetime.timedelta(days = 1)).isoformat()

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

Not opposed, but you'd need to set your requirements more clearly.  Do you
want the whole "/groups" hierarchy to be fetched over HTTP on demand?
A subtree?  Individual groups?

-- Juliusz