Configs for initialization with custom non-root PODs

[jeswr]

Feature description:

I noticed that there is now a ConfigPodInitializer so in my understanding it should now be possible to define some configs that create a few sample users on startup (for example for a test environment).

Are there sample configs on how to do this for non-root users - (I can only see ones for root users in the initializers configs). I made the following attempt of my own, but was not sure how to correctly configure the WebID - nor what the appropriate values for storageKey were.

{
  "@context": "https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/^2.0.0/components/context.jsonld",
  "@graph": [
    {
      "comment": "Makes sure the root container exists and contains the necessary resources.",
      "@id": "urn:solid-server:default:PodInitializer",
      "@type": "ConditionalHandler",
      "storageKey": "foo",
      "storageValue": true,
      "storage": { "@id": "urn:solid-server:default:SetupStorage" },
      "source": {
        "@type": "ContainerInitializer",
        "args_baseUrl": { "@id": "urn:solid-server:default:variable:baseUrl" },
        "args_path": "/wright",
        "args_store": { "@id": "urn:solid-server:default:ResourceStore" },
        "args_generator": {
          "@type": "TemplatedResourcesGenerator",
          "templateFolder": "@css:templates/pod",
          "factory": { "@type": "ExtensionBasedMapperFactory" },
          "templateEngine": { "@type": "HandlebarsTemplateEngine" }
        },
        "args_storageKey": "foo",
        "args_storage": { "@id": "urn:solid-server:default:SetupStorage" }
      }
    }
  ]
}

Happy to create a couple of such configs for others to use in dev environments if I can be pointed in the right direction for solving these problems.

[joachimvh]

I noticed that there is now a ConfigPodInitializer so in my understanding it should now be possible to define some configs that create a few sample users on startup (for example for a test environment).

This is actually an "old" feature that was added before the first release of CSS, but not iterated upon afterwards due to shifting priorities. It's not exactly what you think it is though so I'll cover what it does here.

ConfigPodInitializer is part of the dynamic pod creation feature, which is enabled by the imports in the dynamic.json config. The idea behind dynamic pod creation is that every individual pod could have its own custom Components.js configuration. This would allow one user to have a file backend for their pod, and another user to have a SPARQL backend or even a composite backend where part of it is used for their hue lights. Registering a pod in such a server takes an extra template parameter, as seen in the corresponding integration test. This string refers to one of the stored templates on the server. The server then uses a router store to the correct instantiated mini-store based on the podname found in each URL.

One issue is that if the server restarts it needs to instantiate all these pods again. That is where the ConfigPodInitializer comes in. Every time a new pod is created on such a dynamic server, its settings (owner, template, name, etc.) are writting to a JSON config. When starting the ConfigPodInitializer it then reads that config file and calls Components.js for each entry.

What the ConfigPodInitializer does NOT do is:

1. Create files in those pods, since those would have been stored in whatever backend.
2. Register those pods in the IdP, since that would have already have happened during registration.

So i don't think the initializer would fit for your use case. If you want to quickly set up a bunch of pods your best bet is to have a JSON list where each entry is a set of parameters that can be sent to the registration endpoint and then a small script that iterates over them and does the POST requests.