Coordinator-level DNA properties

[mattyg]

I want the ability to configure settings for my DNAs without altering the code and without using DNA properties (to avoid breaking integrity hash). Think how .env files are often used in other frameworks, except that end-users could modify these properties themselves for their installed apps.

My proposal is we add coordinator_properties to the DNA manifest (outside of the modifiers), and add a function in dna_info() to read them. Or alternatively add an additional (optional) settings.yaml file to the packed dna.

Interested in hearing other options / approaches. I see a foot guns where coordinator properties are read in integrity code, and where properties are overwritten due to not being scoped by zome.

[matthme]

Without having thought about it thoroughly - is hard-coding such properties directly in the coordinator zome code not an option?

[pdaoust]

When separate needs become entangled together like that, I sorta feel like it indicates a justification for redesigning something :)

[mattyg]

When separate needs become entangled together like that, I sorta feel like it indicates a justification for redesigning something :)

agreed but there's a trade off of making minor incremental changes in short timeframes vs. large redesigns on longer timeframes. Larger redesigns need broader buy-in, review, reflection and political capital to get prioritized. Incremental ones can be relatively minor tasks that get slotted into normal work routine.

[pdaoust]

true true, and a very pragmatic take. I can picture that, at a certain point, if all the incremental changes were made carefully, the large-scale change might be so obvious and easy that it'd take more work to not make the change. Wishful thinking, perhaps, given how many incremental changes take shape... I think I'm just seeing a lot of these cases where there's more friction in keeping a design than reworking it.

[maackle]

And would they (need to) span all coordinator zomes?

Not important to me either way

I agree that it's hard to get momentum on a redesign and that we want to be able to improve incrementally. However I think it's important to think through all these little details before considering even a minor incremental change. Part of the reason we are a bit challenged by the current design is precisely because we made some incremental changes without thinking through all the consequences, such as adding the ability to update coordinators without fully thinking through what that means for existing cells using the same DNA.

So even if the choices are arbitrary, let's think them through all the way. I invite the participants to fully answer @matthme's question about how this should interact with coordinator updates.

[mattyg]

I would expect these non-modifier properties follow the same pattern as the modifier dna properties.

If / when we refactor dna properties to be scoped by zome, then I would want these to be scoped by zome as well. Until then, I wouldn't.

And would they (need to) span all coordinator zomes? Because update_coordinators() will only update selectively and not touch any coordinator zomes that have not been passed to update_coordinators(). So changing the structure of such coordinator_properties may be problematic in cases where only a subset of coordinator zomes get updated.

If the non-modifier properties are not scoped by coordinator zome, then they wouldn't be updatable via the update_coordinators() function.

If they don't need to span all coordinator zomes then it's maybe similar to the request to have zome_properties. But including coordinator zomes...

If the non-modifier properties are scoped by coordinator zome, then yes this seems perfect.