If changes occurs during runtime we also clear affected caches. So we can change configuration/files during runtime and still use an accurate cache because the cache is cleared/updated accordingly.
When hosting on OpenShift/Kubernetes configuration and resource-files can be handled with ConfigMap's. You can create a ConfigMap for a whole directory. I have experienced issues with this, file-system changes are triggered even if you not expect it. Can not explain it better than that.
I think it would be an enhancement to have the opportunity to use a "hard" cache if you want to. A cache that is never cleared during runtime. You need to restart the pod to get new localizations/resources. I think this should not be handled with a configuration-flag, like ClearCacheWhenNecessary = true (just an example). Instead we should be able to configure services at startup for different ResourceProviders and LocalizationProviders, by adding type properties for that in our options:
public virtual Type ResourceProviderType { get; set; } = typeof(ResourceProvider);
These types can initially be set to a default type. But can be configured so that another type is used. You can even build your custom type if you want. We also need a TypeTypeConverter registered at startup so the configuration-system can handle binding of the Type type.
And we should than also build hard-cached LocalizationProviders and ResourceProviders, eg:
HansKindberg
commented
1 year ago
We cache localizations/resources for better performance:
If changes occurs during runtime we also clear affected caches. So we can change configuration/files during runtime and still use an accurate cache because the cache is cleared/updated accordingly.
When hosting on OpenShift/Kubernetes configuration and resource-files can be handled with ConfigMap's. You can create a ConfigMap for a whole directory. I have experienced issues with this, file-system changes are triggered even if you not expect it. Can not explain it better than that.
I think it would be an enhancement to have the opportunity to use a "hard" cache if you want to. A cache that is never cleared during runtime. You need to restart the pod to get new localizations/resources. I think this should not be handled with a configuration-flag, like ClearCacheWhenNecessary = true (just an example). Instead we should be able to configure services at startup for different ResourceProviders and LocalizationProviders, by adding type properties for that in our options:
RegionOrebroLan.Localization.Configuration.LocalizationOptions.LocalizationProviderType
public virtual Type LocalizationProviderType { get; set; } = typeof(LocalizationProvider);
RegionOrebroLan.Localization.Configuration.LocalizationOptions.ResourceProviderType
public virtual Type ResourceProviderType { get; set; } = typeof(ResourceProvider);
These types can initially be set to a default type. But can be configured so that another type is used. You can even build your custom type if you want. We also need a TypeTypeConverter registered at startup so the configuration-system can handle binding of the Type type.
And we should than also build hard-cached LocalizationProviders and ResourceProviders, eg:
The above is just an example regarding the names.
Maybe we also should rename our default providers to something else, I don't know:
But we need caching. If we did not cache, files should be read all the time and that is not good regarding performance.