fa78bc6856
test: unit test succeeds fix: not quiting loop when releasing unexisting lock refactor: pull wait() function into TimerUtils feat: store all locks inside a single lock folder feat: use md5 hashing for filepath hashes test: coverage back to 100% fix: store locks in proper .internal/locks folder feat: reworked tryfn test: coverage back to 100% buidl: package json types next to lib style: linting dos: add more documentation to Locker classes refactor: SingleThreadedResourceLocker -> MemoryResourceLocker refactor: MultiThreadedResourceLocker -> FileSystemResourceLocker feat: update all file-based backend configs to use the new FileSystemResourceLocker feat: add warning on starting the MemoryResourceLocker in a worker process test: coverage back to 100% fix: finalizer of file.json was configured wrong docs: updated release notes for 5.0.0 refactor: incorporated changes so far refactor: retryFunctions are less complex now test: jitter fix
This folder contains several configurations that can be used to start up the server.
All those configurations are created in the same way:
features are enabled or disabled by choosing a specific option for every component.
All components are represented by the subfolders found in the folders here:
ldp contains all LDP related components,
identity all IDP components, etc.
Options are then chosen by importing 1 entry from every component subfolder.
In case none of the available options have the exact feature configuration you want,
it is always possible to not choose any of them and create your own custom version instead.
How to use
The easiest way to create a new config is by creating a JSON-LD file
that imports one option from every component subfolder
(such as either allow-all.json or webacl.json from ldp/authorization).
In case none of the available options suffice, there are 2 other ways to handle this:
Append to an existing config
In case the options mostly suffice, but they just need to do a bit more, it might be possible to append to one of the solutions.
For example, in case all the existing metadata parsers can remain,
but an additional one needs to be added,
you could import ldp/metadata-parser/default.json
and then add the following in your root config:
{
"@id": "urn:solid-server:default:MetadataParser",
"@type": "ParallelHandler",
"handlers": [
{ "@type": "MyNewParser" }
]
}
This will add the new parser to the list of metadata parsers.
The @id value is needed so Components.js knows which object to add the values to,
and the @type is needed so it can interpret the other fields (handlers in this case).
Note that generally it is only advised to append to ParallelHandlers or key/value maps. In case the order is important this can not be guaranteed over separate files.
Create a new option
If a more drastic change is required, the solution is to not import anything from that folder but instead write your own.
For example, in case you only want the slug parser but not any of the others,
you would have to not import anything from ldp/metadata-parser folder,
but instead have the following in your root config:
{
"@id": "urn:solid-server:default:MetadataParser",
"@type": "ParallelHandler",
"handlers": [
{ "@type": "SlugParser" }
]
}
Don't forget that in some cases you would also have to copy some imports! The existing options can be used as inspiration.