Add string based backend

[ktf]

A URL format as:

str://key=value;key2=value2;key2.key3=value3...

is interpreted as a ptree.

[ktf]

@awegrzyn @vascobarroso with this DPL ConfigParamSpecs can be configured with (almost) the same syntax that ConfigurableParam uses for the command line, i.e.:

str://key=value;key2=value2;key2.key3=value3...

which is one of (my understanding of) the complains of @shahor02 for the DPL UI of the configuration mechanism. Ruben with this you can do:

--cfg str://key=value;key.key2=value2;key.key2.key3=value3

to set the values declared by ConfigParamSpec. I will add later some sugar to drop the need for str://. Notice that one needs to declare only "key" as ConfigParamSpec, if you use it as a ptree (or you could also the ROOT based mechanism showcased in the meeting).

[awegrzyn]

@ktf LGTM, do you mind if I add some docs and unit test before merging?

[ktf]

@awegrzyn sure. Do you want me to do them?

[awegrzyn]

nah it's fine, I'll do it, I expect to do some refactoring anyway.

[ktf]

I was actually thinking one cool thing to have would be to pass a LUA script to create the options in a programmatic way. ;-)

[awegrzyn]

Sure, but not sure I understand fully. Just lemme know how do you prefer to proceed.

[ktf]

That was an half joke and not for this PR... ;-)

[teo]

@ktf Any reason for using ; as separator?
If it was , the input would be valid CSV, same as e.g. Ansible and AliECS parameter input.

[awegrzyn]

Good to go from my side although I'm also interested about ; vs ,

[ktf]

From my point of view, just compatibility with what is done elsewhere in O2. I agree "," would be better / more natural. @sawenzel @shahor02 might have a reason why it was not done that way for ConfigurationParam?

[sawenzel]

I think it it's because ConfigurableParam supports vectored assignment (like an initializer list) for which we use ',' to follow C++ notation.
Example: "Foo.3dpos={1,2,3};Bar.x=3."

[ktf]

@sawenzel ok, understood, albeit Foo.3dpos={1,2,3},Bar.x=3 or even better Foo.3dpos=[1,2,3],Bar.x=3 would work as well no? The advantage of the latter being not requiring escaping when passing it on the command line. Anyways, I suggest we merge this and we keep the discussion in mind for later.

[sawenzel]

anything works as long as you parse it correctly

[ktf]

maybe I misunderstood your comment, but my point is that bash would choke on Foo.3dpos={1,2,3};Bar.x=3 unless you quoted it or escaped the { } ;, because they have a special meaning. Anyways, I guess we agree that we should start with a compatible implementation and then evolve it, if needed / required.