Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration Page for Jitsi Web Configuration #294

Open
DanielHabenicht opened this issue Mar 23, 2022 · 10 comments
Open

Configuration Page for Jitsi Web Configuration #294

DanielHabenicht opened this issue Mar 23, 2022 · 10 comments

Comments

@DanielHabenicht
Copy link
Contributor

I was looking to document the feature I hopefully add in jitsi/jitsi-meet#11052 but did not find a matching page.

Should we add a new page for jitsi-web configuration in the "Self-Hosting Guide / Configuration" Section?
It would document features like Youtube, Etherpad etc.
Or even some normal modification like changing the icon.

@saghul
Copy link
Member

saghul commented Mar 23, 2022

Sounds good yeah!

@damencho
Copy link
Member

The generic iframe is in PR and is no ot yet part of the project.

@DanielHabenicht
Copy link
Contributor Author

DanielHabenicht commented Mar 23, 2022

sure, I will only create the page documenting what is in master.

@saghul
Copy link
Member

saghul commented Mar 23, 2022

That's what I understood, FWIW :-)

@DanielHabenicht
Copy link
Contributor Author

DanielHabenicht commented Jul 1, 2022

While adding the feature descriptions, is there a clear distinction between Configuration and Deployment? Because it kind of blends together in the guide.
E.g. Docker has its own Configuration section: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker#configuration

Also can I introduce a third folder level to the documentation?
docs/devops-guide is getting confusing with all the files for "Configuration" and "Deployment" mixed together.
I would seperate them in:
docs/devops-guide/deployment and docs/devops-guide/configuration

@saghul
Copy link
Member

saghul commented Jul 1, 2022

On the web part we have a general configuration section, which is where I think this belongs.

Docker is different because it translates environment variables into the aforementioned config.

2 similar comments
@saghul
Copy link
Member

saghul commented Jul 1, 2022

On the web part we have a general configuration section, which is where I think this belongs.

Docker is different because it translates environment variables into the aforementioned config.

@saghul
Copy link
Member

saghul commented Jul 1, 2022

On the web part we have a general configuration section, which is where I think this belongs.

Docker is different because it translates environment variables into the aforementioned config.

@DanielHabenicht
Copy link
Contributor Author

On the web part we have a general configuration section, which is where I think this belongs.

you meant https://jitsi.github.io/handbook/docs/dev-guide/dev-guide-configuration ? This is kind of tugged away for, maybe it should be moved to the "self hosting guide/configuration" section?

Docker is different because it translates environment variables into the aforementioned config.

They are named a little bit different but they do nothing else (at least the web configuration variables). I would vote for it being all in one, e.g.

as table:

config.js Option Docker-Jitsi-Variable Example Description Remark
etherpad_base ETHERPAD_URL_BASE http://etherpad.meet.jitsi:9001 If set, it adds a "Open shared document" link to the bottom right menu that will open an etherpad document. You may need to add 'etherpad' to the buttons section.

Like the sectioning already done:

etherpad_base

type: String

If set, it adds a "Open shared document" link to the bottom right menu that
will open an etherpad document.

Examples:

etherpad_base: 'https://your-etherpad-installati.on/p/'
  ETHERPAD_URL_BASE: 'https://your-etherpad-installati.on/p/'

The examples could be structured with multi language tabs.

Or one could use tabs in general.

The benefit would be that the same configurations aren't split between two files and do not have to be documented twice, as they are currently, e.g.:

@saghul
Copy link
Member

saghul commented Jul 5, 2022

The problem is that not everything maps one to one. Related to config.js sure, but putting every component's config together would be too large IMHO.

I agree the current situation is not great and could be improved.

Maybe a way to split them is semantically. You'd have options related auth for example, transcriptions, etc, which require multiple components, and then the core config.js reference, which would indeed have tabs or a table or something to reference the Docker counterpart.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants