Requirements
Inspired by open-feature/dotnet-sdk#56
The global singletons (e.g. provider, evaluationContext, logger) all share a mutex to ensure thread safety, however a client doesn't use a mutex so there's a concern if two processes want to set an evaluation context for example.
The EvaluationContext type has the field Attributes of type map[string]interface{}. In go, maps are always passed by reference, this means that in theory one could pass an EvaluationContext to a client's flag evaluation call and continue to alter the Attributes' map in another process.
This could be avoided by making the Attributes field unexported with an exported constructor for EvaluationContext, this would mean that an application author couldn't change the field once constructed. However, an author could still alter the map they passed as a parameter to the constructor, which is the same map used in struct (passed by reference). In order to avoid this the constructor would need to initialise a new map and copy the map passed as a parameter.
Is this overkill? Is there a better solution we can come up with?
cc @beeme1mr @toddbaert @james-milligan
Requirements
Inspired by open-feature/dotnet-sdk#56
The global singletons (e.g. provider, evaluationContext, logger) all share a mutex to ensure thread safety, however a client doesn't use a mutex so there's a concern if two processes want to set an evaluation context for example.
The
EvaluationContexttype has the fieldAttributesof typemap[string]interface{}. In go, maps are always passed by reference, this means that in theory one could pass anEvaluationContextto a client's flag evaluation call and continue to alter theAttributes' map in another process.This could be avoided by making the
Attributesfield unexported with an exported constructor forEvaluationContext, this would mean that an application author couldn't change the field once constructed. However, an author could still alter the map they passed as a parameter to the constructor, which is the same map used in struct (passed by reference). In order to avoid this the constructor would need to initialise a new map and copy the map passed as a parameter.Is this overkill? Is there a better solution we can come up with?
cc @beeme1mr @toddbaert @james-milligan