Re: [config-dev] Config Source SPI options

[Mark Struberg <struberg@xxxxxxxxxx>]

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.


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

> 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.

> 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.


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://docs.google.com/document/d/1faUyGMEzwOp9vio8IvHpl5Vcyqg-v3iQCFTV19BxF5Y/edit?usp=sharing.
> 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://accounts.eclipse.org