Suggestion: Create a very simple web tool that can be used to create a configuration file

[stefandesu]

This could make it easier for people to set up their own Cocoda instances. The tool could use the default config as a base and then let people add or remove registries and change the title and logo, and so on.

[nichtich]

How about admin access to directly edit the config file via web? Each version of the configuration should be kept for rollback and transparency.

[stefandesu]

I like the idea! Should this be something that is available to all Cocoda instances? Because currently, Cocoda can be served as static files, but this would require a backend service.

[nichtich]

Cocoda should not require a backend service by default and this feature is more relevant to setting up new instances (unless it also covers saving user settings). Maybe an independent service to manage cocoda instances?

[stefandesu]

Yeah, an independent service would have been my suggestion as well. Crazy idea: This service could also be used to manage jskos-server instances in addition to Cocoda instances. Maybe a simple web tool to add or edit schemes/concepts, and maybe have statistics about how many mappings there are and stuff. What do you think?

[stefandesu]

For editing JSON, instead of creating our own editor, we could use an existing editor that's using JSON Schemas for building a form. Here are some examples:

• https://github.com/jsonform/jsonform
• https://github.com/json-editor/json-editor
• https://github.com/josdejong/jsoneditor
• https://github.com/gitana/alpaca

[stefandesu]

This could be published as a separate Docker image or included in the Cocoda Docker image so that configuring instances via Docker is easier.

[stefandesu]

Alternatively, we could offer a simple web service that

• offers the functionality described here (building a Cocoda config file via the UI),
• integrates with Login Server so that users can save their configurations in our database,
• and offers a URL for each saved configuration that can simply be given as a URL parameter to our default instance.

The advantage would be that people could create their own "flavor" of Cocoda without any hosting on their part, and we would only need to have one more database running. As long as the tool is kept simple, I don't see it as a problem. Also, people could then use our Login Server even with their own jskos-server instances because they'd use the Cocoda instance hosted on our domain (only with a different config file).

[nichtich]

Revisited after a year, this issue and #353 look like too much complexity for little use, so better close this.

[stefandesu]

I still think it would be valuable to have, especially if people start setting up their own instances of Cocoda, but it's definitely very low priority and currently there is no demand for it.

I might implement something extremely simple at some point though, like a web form that gives you the JSON for the Cocoda config file or something. 😉