Allow overriding values

[joachimvh]

Issue type:

• ➕ Feature request

---

Description:

The idea is to add an option so values that have been set in a different (imported) config can be overridden. For example in CSS we have the following config:

    {
      "@id": "urn:solid-server:default:ResourceLocker",
      "@type": "WrappedExpiringReadWriteLocker",
      "locker": { ... },
      "expiration": 3000
    }

This is one of the configs that gets imported into the main config to set up the locking system. If a user wants to change the expiration time of the locks, they would have to copy everything in this import somewhere else, change the expiration value, and import that config instead (or copy it into the main config).

It would be nice if instead something like this could be added to the main config instead:

    {
      "@id": "urn:solid-server:default:ResourceLocker",
      "@override": {
        "WrappedExpiringReadWriteLocker:_expiration": 5000
      }
    }

Which would make it much easier for users to adapt existing configurations.

The disadvantage (besides potentially being complex to implement) is that if you start from a config that already has an override value, there is no way to override it again. Perhaps a weight system could be used there but that would increase complexity.

Potentially there are also other possible solutions, but in general the ability to change the value of a parameter from an imported config would make several situations much easier.

[github-actions]

Thanks for the suggestion!

[rubensworks]

I understand the need (have run into this problem myself as well), but not sure about the override mechanism.
The problem with it is that it assumes some kind of order in which components are created, while in RDF-world, these all just exist at the same time.

---

An alternative that could work is that you could instantiate a new config (with a different id), and allow it to extend from an existing config. But since that would result in a different id, perhaps it's less useful in your case. (but it could give you to option to provide some reusable presets).

---

Another alternative is to make more use of the default values of parameters (which we do quite extensively in Comunica). If the user instantiates a component, it can either use the default param value, or provide a custom value.

[joachimvh]

I understand the need (have run into this problem myself as well), but not sure about the override mechanism. The problem with it is that it assumes some kind of order in which components are created, while in RDF-world, these all just exist at the same time.

I had hoped that the suggestion above would be RDF-like enough to still be ok, since all the information stays present and in scope of the original subject. But yes, it is not completely pure.

An alternative that could work is that you could instantiate a new config (with a different id), and allow it to extend from an existing config. But since that would result in a different id, perhaps it's less useful in your case. (but it could give you to option to provide some reusable presets).

I'm not exactly sure what you mean by this, can you provide an example?

Another alternative is to make more use of the default values of parameters (which we do quite extensively in Comunica). If the user instantiates a component, it can either use the default param value, or provide a custom value.

We also do this sometimes, but it's not always possible. Here it would be an option indeed. But another disadvantage (and perhaps the reason I use it less often) is because it makes it less clear to the user which values are present and can be changed. I want to provide as much information as possible to the user so they can adapt a config to their needs without needing to go look into the code. We also have some configs that are always invalid but provide an example of which parameters need to be set. E.g., a HTTPS config showing which parameters need to contain the key/cert values.

[rubensworks]

I'm not exactly sure what you mean by this, can you provide an example?

    {
      "@id": "urn:solid-server:default:ResourceLocker2",
      "extends": "urn:solid-server:default:ResourceLocker1",
      "WrappedExpiringReadWriteLocker:_expiration": 5000
    }

[joachimvh]

    {
      "@id": "urn:solid-server:default:ResourceLocker2",
      "extends": "urn:solid-server:default:ResourceLocker1",
      "WrappedExpiringReadWriteLocker:_expiration": 5000
    }

I did not realize that this is something that I could do, might allow for some interesting options for the config (or not, would have to look into it more). But indeed, that does not help for this specific problem with our configs due to the different ids.

[rubensworks]

I did not realize that this is something that I could do

You can't do it atm, but it could be implemented :-)

[renyuneyun]

Some interesting side notes related to this issue and discussion:
Based on my tries, although not documented and against the basic assumption, that the current implementation do have some sort of ordering:

• If the same ID appears in two files in import, the earlier one takes precedence.
• If the same ID exists in the current file (and also in someone from import), the one in the current file takes precedence.

This may not be complete, but is consistent during my tests.

It would be nice to give some warnings, if having multiple nodes with the same ID is against the principle.