Sorry Dmitry, yesterday in the call we all decided that the VOTE thread would be done AFTER the discussion happens!
So this VOTE is premature without people knowing on WHAT they actually VOTE on.
Because your 'TREE' proposal internally is also FLAT!
The only question actually is WHEN it is expanded back to objects again.
The whole question of TREE vs FLAT is actually misleading, because BOTH proposals can deal with native tree like ConfigSources but internally flatten em up to String/String because it's still the least common denominator.
The full picture is more like that the underlying configuration mechanism always are TREE (JSON, yaml, XML) *and* FLAT (Properties, Environment, Docker env, kubectl, database, etc).
BOTH can represent objects and flattened out. E.g. via XPath and JsonPointer and dotted notation.
This is the reason that BOTH proposals have String/String in the ConfigSource and NOT a TREE.
If you really want a TREE based configuration mechanism then you would also need to go TREE in the ConfigSource and replace whole Objects. Which is NOT what your proposal does!
Calling it TREE vs FLAT is just misleading...
LieGrue,
strub
Hi,
Here is a ballot thread to vote for tree structure vs flat structure.
Vote +1 if you prefer to use TREE structure in Jakarta Config
Vote -1 if you prefer to use FLAT structure in Jakarta Config
Vote 0 if you don’t care.
PLEASE DON”T ADD ANY EXPLANATION TO VOTES, POST ONLY +1, -1 or 0.
For discussions use another thread with a subject “Tree structure vs flat structure discussion thread”.
The ballot ends right before our next week meeting on Tue, Dec 16 at 16:00 CET.
Thanks,
Dmitry
