User-level configurations and/or user-configurable components/classes

[renyuneyun]

(This PR emerged from https://github.com/KNowledgeOnWebScale/solid-calendar-store/issues/31.)

Background and motivation:

At the moment, the CSS configuration is done on a whole-server basis: when starting the server, a parameter is used to tell it what configuration file is used. In some cases, there will be benefits if some configurations can be done on a per-user (per-pod) basis, and the relevant components/classes can be used on a per-user basis.

For example, the Solid Calendar Store uses additional routing rules in the configuration file to define additional API endpoints for exposing (transformed) calendars. It currently does that at the root of the server, and therefore forces the server to host only one pod on its root (otherwise the users won't have the custom API endpoints, which makes the calendar store useless for them). If each user can define their own configurations for the calendar store, the server can have multiple users/pods as it is expected to be. As per the discussion in https://github.com/KNowledgeOnWebScale/solid-calendar-store/issues/31, CSS cannot do that on a per-user basis at the moment; it has the potential but is missing some pieces for achieving that.

Feature description:

• Add a way to incorporate user-level configurations (e.g. a unified way to specify a location for user-level configurations in the main configuration file).
• Allow some components/classes to be customized on user-level.
• (Additional) Dynamically reload the user-level configurations while the server is running.

Additional information:

There is a dynamic.json configuration file, which may be related to this feature request. But there is a lack of documentation of what it means by "pod provisioning", and a lack of explanation on how to use it. Similar situation also happens to the path-routing.json configuration file.

It feels like simply "importing" the user-level configurations is not enough currently, because the routing rules need to be heavily customized for each user explicitly. But maybe some complicated (or clever) ways of using it may make this possible? I'm not sure.

[joachimvh]

CSS cannot do that on a per-user basis

It can do this, but it requires more advanced Components.js knowledge and usage of some more hidden components. And some of those components should be upgraded to be more in line with the current architecture. The current solution wouldn't work in a multithreaded setup for example (#726). It also doesn't use the internal storage yet since that didn't exist when this was added.

• Add a way to incorporate user-level configurations
• Allow some components/classes to be customized on user-level.

This is indeed what the dynamic.json setup does. When registering, an extra template parameter can be sent along to choose which components.js template should be used to create the pod then. There is no visual interface for this though (#754). The value for this parameter should be the filename that is in the template folder. That folder is by default this one: https://github.com/CommunitySolidServer/CommunitySolidServer/blob/b3da9c9fcfb642e8a8a6d537b2e69cbd74ee8a88/src/pods/generate/TemplatedPodGenerator.ts#L14 But can be set through a parameter for this class. (The above path is also one of the things that should be upgraded since it doesn't use our internal path functions yet).

Included in the functionality is a special routing component that routes requests for every pod to the store exported in their respective configs to make this all work.

Similar situation also happens to the path-routing.json configuration file.

What can help here is to look at the imports where it differs from the other default configs. This one specifically has a different backend import that does all the routing: https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/config/storage/backend/regex.json