User-level configuration?

[renyuneyun]

Right now, the README describes that the (calendar) configuration should be loaded upon service start. It assumed the server is for a single user (pod) sits on the root.

Is there a way to allow the server to serve multiple pods, and each of them have their own calendar configurations as a file?

[pheyvaer]

Hi @renyuneyun, good question! @joachimvh do you know of way of doing this?

[joachimvh]

In theory yes, but not easily. So in practice not really.

You would either need a solution with some new custom classes to track the calendar information of users when they register, or you would somehow need to have a custom Components.js configuration for every pod that contains the calendar URL and the correct routing as the root config does in this project.

CSS actually has support for having a custom Components.js configuration per pod, but this feature is mostly hidden because there never was a real need for this. Some of the relevant components might also need to be upgraded as these were made when the internal storage architecture was not yet fully set.

Even with different configurations per pod, some changes would still be needed somewhere so the user could send along their calendar URL during registration.

[renyuneyun]

Hi both. Thanks for the comments.

Indeed, I was thinking of the mechanism for custom configuration per pod, and found that the config/dynamic.json configuration may serve this purpose (but never managed to get it working, and did not find documents).

... this feature is mostly hidden because there never was a real need for this

Now there is a use case :)

... some changes would still be needed somewhere so the user could send along their calendar URL during registration.

I guess this is not the most problematic part, as currently solid-calendar-store also does not provide a UI for configuration. Server maintainers should be able to cope with that.

A different question would be more meaningful here: is it possible for the configuration to be dynamically reloaded while server is running?
More specifically, for the calendar case, can the router rules be dynamically reloaded, per user pod?
To be fair, this is not a hard requirement, but will be a very valuable bonus.

[joachimvh]

A different question would be more meaningful here: is it possible for the configuration to be dynamically reloaded while server is running?

No. Not for the whole server at least. This is why for those dynamic pod configurations we need several utility classes that modify the routing on the fly. This all happens in memory currently, which is one of the issues with the feature since this means this probably won't work with multithreading.

If you want to modify your main components.js config every time a new user gets added you would have to restart the server every time.

[renyuneyun]

Thanks for the reply.

If you want to modify your main components.js config every time a new user gets added you would have to restart the server every time.

That matches my intuition.
For other use cases, this may be a problem. But for the calendar store, I think this won't be a big problem because the calendar configurations will not be updated frequently. Having the per-pod-configuration ability should be more critical than other things.

Our team is thinking of deploying CSS servers (with the calendar store), to be tested in our team. Having to set up one server per user is really a pain, let alone that everyone will still update their configurations and need to restart their servers.

[pheyvaer]

Having to set up one server per user is really a pain, let alone that everyone will still update their configurations and need to restart their servers.

Is there not a way to automate this? In the past I created scripts to use a template config and fill in the calendar URL.

[renyuneyun]

Is there not a way to automate this? In the past I created scripts to use a template config and fill in the calendar URL.

Possible for the server (process) part, but hard for the DNS part -- it's doable in principle, but we don't have the relevant experience.

And when users want to update their config, manual intervention is still needed. This is the same situation for a single server process with different configurations for different pods; while single-process-multiple-config-different-pods will save the effort in DNS and web reverse proxy configuration.

[pheyvaer]

@renyuneyun Yeah I see what you mean. The DNS and reverse proxy thing I do that manually, because our office is around 30 people so that is still doable.