Hi Julian yes, we considered YAML. First of all, the OSGi Configuration Admin specification will use JSON. That spec started with using YAML, but in the end no one was happy with the format, so we replaced YAML with JSON.
While YAML can support JSON, no one really does this - so we end up with real YAML and JSON mixed. Which is confusing. And YAML is not practical as soon as your document gets to a certain size. Or in other words :) I'm very much opposed to using YAML. Let's keep it simple and JSON works fine. The JSON comments are based on what everyone seems to use ([1]). It's easy to explain and easy to process. Regards Carsten [1] https://github.com/douglascrockford/JSMin Julian Sedding wrote > Hi Carsten > > This looks very interesting! > > Regarding the format, have you considered YAML? It is a superset of > JSON (well, it's designed to also support JSON syntax) and it allows > comments out of the box. Furthermore, it's well specified (in contrast > to JSON with comments). I assume that using YAML, people could choose > whether they want to write it more JSOn style or YAML style. > > Regards > Julian > > > On Wed, Oct 4, 2017 at 10:12 AM, Robert Munteanu <romb...@apache.org> wrote: >> On Wed, 2017-10-04 at 10:01 +0200, Carsten Ziegeler wrote: >>> Robert Munteanu wrote> On Tue, 2017-10-03 at 11:52 +0200, Carsten >>> Ziegeler wrote: >>> >>>>>> 2. Reading the section on configuration merging, it is not >>>>>> clear to >>>>>> me >>>>>> if merging is merging of values or overriding of values. >>>>>> >>>>>> Consider >>>>>> >>>>>> >>>>>> feature 1: >>>>>> >>>>>> com.foo.bar.Service >>>>>> prop1="A" >>>>>> prop2="B" >>>>>> >>>>>> feature 2: >>>>>> >>>>>> com.foo.bar.Service >>>>>> prop1="C" >>>>>> >>>>>> >>>>>> After the merge, will the configuration define the prop2 >>>>>> property? >>>>> >>>>> Yes, values get overwritten. >>>> >>>> Is there any way of removing a configuration property once it's >>>> defined >>>> in a feature? >>>> >>> >>> Yes, if a feature is includes other features, the include instruction >>> can have any number of removals. >>> So you can remove properties before, bundles etc. >> >> >> So I guess we have most (or even all) annoyances from the provisioning >> model covered, which is great. >> >> Thanks, >> >> Robert -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
