search

xregistry / spec

xRegistry related specifications
https://xRegistry.io
Apache License 2.0
35 stars 6 forks source link

Instance specific configuration #150

Closed duglin closed 1 month ago

duglin commented 2 months ago

This is related to: #145 , #148

Not all instances of Resources will share the same configuration. Today we have the "readonly" flag on the Resource model definition but often there are cases where only selected instances of those Resources are read-only. For example, system defined schema might be read-only, while user defined schema is not. Similarly, some schemas might required newer versions to be backwards compatible, while other schemas may have a different compatibility policy (or even none).

We need a way for people to configure and expose configuration options at a more granular level than the model definitions. We may need to allow them to be specified at the Registry(model), Group instance or possibly Resource instance levels. However, should a user of the registry need to check all 3 levels to determine if a Resource instance is read-only? Ideally, a read-only flag set at any higher level should trickle down to the owned Resources so the user can see that flag on the Resources directly.

Do we need to worry about Registry or Group level config flags that should not be copied into the child Resources? Probably.

Is setting a config flag at one level setting the default value for future child entities, or does it change the value for all child entities immediately? I'm leaning towards changing the children.

There are 4 parts that we need to design: 1 - how to express a configuration option, regardless of the level in the hierarchy? Probably similar to how we define attributes - perhaps in a new "config" section in the model where they can be specified within the Reg, Group or Resource definitions. 2 - how to deal with the inheritance issues? how does it work and how to control it? 3 - how do people find out which config options are available? 4 - what spec defined config options should we have? read-only (bool)? compat policy (string)? others?

Or should we just let people define extensions at whatever level they want. E.g. define a "readonly" extension for MessageGroups and people need to look at the group's "readonly" attribute to know if that message is editable?

duglin commented 1 month ago

closing for now as I think we'll try to try do deal with it on a case-by-case basis. Might reopen if needed.