Re: [config-dev] [External] : Re: Config Source SPI options

[Tomas Langer <tomas.langer@xxxxxxxxxx>]

> On 5 Aug 2021, at 12:46, Mark Struberg <struberg@xxxxxxxxxx> wrote:
> 
> Hi Thomas et al!
> 
> 
> Agree with Section "Config Source SPI" and good thoughts in "Content Type".
> 
> 
> Ad "Eagerness": What do you mean with 'lazy sources'? ConfigSources added at runtime? Or the content (key/value) added/changed at runtime? Whenever you have something like a config served by a Database or a remote server then you will hit the later.
> 
Lazy source: a source that cannot list the full set of provided options. E.g. you need to request a key to find out if it exists or not.
> 
> Ad "Mutability". If we do not support mutable config we loose a lot of use cases.
> 
>> Such a solution cannot use any caching on Config implementation
> 
> Not really true. Look at DeltaSpike Config. The 'last modified' allows for rather good caching and fast cache eviction. Of course it's a bit tricky
What is last modified? Is that specific too DeltaSpike? If your source can provide such information, it is definitely good - but I do not see this in the current MP spec, which I use as the API/SPI I check against. Question would be if a source is capable of providing such information for all its configuration keys, or if that may be limited to a single key.
> 
>> this also allows for inconsistent configuration (if you load two keys in sequence, each from a different version of underlying source)
> 
> The 'ConfigValue' solution did solve this but I understand that it's really too complicated. Resolving a POJO config could way easier be guaranteed to be atomic.
Resolving a pojo does not help, if config queries each source for each property. You would need to have a method on config source that provides more than one value “atomically"
> 
>> Mutability supported by config - config understands mutability options and each config source declares what kind of mutability it supports.
> 
> I'd need more info what you have in mind. First thought is that the evaluation rules might be a tad complex.
The rules are a bit complex - e.g. you know that the first source is mutable, second immutable etc. you would be able to optimise property lookup.
> 
> 
> LieGrue,
> strub
> 
> 
> 
> Am 22.07.21 um 18:57 schrieb Tomas Langer:
>> After today’s discussion on the meeting, I have written a document with various options for config sources - https://urldefense.com/v3/__https://docs.google.com/document/d/1faUyGMEzwOp9vio8IvHpl5Vcyqg-v3iQCFTV19BxF5Y/edit?usp=sharing__;!!ACWV5N9M2RV99hQ!bNxAxwaxvCZa9Aa3DcP0IN21JNiI2Jds0DyT7GmioGuNpynvxyzemsXNBtQ4kdg6xQ$ .
>> It outlines all the options that config source (theoretically) can have, and main decisions we are facing (and an attempt to describe some impact of those decisions).
>> 
>> The shape of SPI will change quite heavily depending on our choices, so we should understand what we want before we design them.
>> 
>> 
>> 
>> Tomas
>> _______________________________________________
>> config-dev mailing list
>> config-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://urldefense.com/v3/__https://accounts.eclipse.org__;!!ACWV5N9M2RV99hQ!bNxAxwaxvCZa9Aa3DcP0IN21JNiI2Jds0DyT7GmioGuNpynvxyzemsXNBtQVshQFZA$ 
> _______________________________________________
> config-dev mailing list
> config-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://urldefense.com/v3/__https://accounts.eclipse.org__;!!ACWV5N9M2RV99hQ!bNxAxwaxvCZa9Aa3DcP0IN21JNiI2Jds0DyT7GmioGuNpynvxyzemsXNBtQVshQFZA$