Sending Config Object Over the Wire about config

[patriknw]

You can get a string representation with config.root.render, which you will be able to parse on the other side. However, we should also consider making Config Serializable, if it isn't that already.

[ayush]

Calling render gives a bunch of extra information. For example if the config object is:

SimpleConfigObject({
"ping-duration" : 2500,
"shutdown-control" : "auto",
"notifications" : "off",
"daylight-savings" : "on",
"currency-precision" : 2,
"image" : {"resize" : "full"},
"thread-pool" : 7,
"suntan" : "some","
ping-poll-duration" : 750,
"mysql" : "mysql.1"
})

a call to render gives http://cl.ly/232F3C3n0F0H0J1G3V3I which has a lot of extra stuff (debugging info) in it.

[havocp]

My eventual intent was to add render(ConfigRenderOptions) where ConfigRenderOptions would be similar in spirit to the existing ConfigParseOptions and ConfigResolveOptions objects. Some possible options are with/without debug comments, with/without pretty indentation, and ConfigSyntax. The existing no-parameters render() would use the default render options (which would be with comments and with whitespace and syntax=CONF).

This should be a straightforward patch if you wanted to attempt it: add ConfigRenderOptions copying how the other Options classes work, then in AbstractConfigValue's protected render() method replace the "formatted" boolean parameter with the options, and tweak the render() implementations accordingly. I think it's as simple as changing "if (formatted)" to "if (options.prettyWhitespace())" and adding some "if (options.comments())" in front of the lines that add comments. Then add some unit tests of course.

Making Config serializable seems sensible as well.

[NicholasSterling]

I am guessing from what you are saying that it will be possible to parse an arbitrary Hocon string and render it as JSON, and vice versa. Is that so? This would be quite useful -- many projects have JSON-based RESTful APIs; this library would be helpful in writing a friendly CLI that talks Hocon with the user and JSON to the server.

[havocp]

Right, that would be the effect. It should be a pretty simple patch, most of the work is writing some tests for it (probably the tests would just round-trip parse the rendered output to be sure the parsed object matches the rendered object).

[NicholasSterling]

The inheritance example is interesting:

data-center-generic = { cluster-size = 6 }
data-center-east = ${data-center-generic}
data-center-east = { name = "east" }
data-center-west = ${data-center-generic}
data-center-west = { name = "west", cluster-size = 8 }

Have you considered allowing additional settings to be put right inside the ${} syntax, or some other shortcut? e.g.

data-center-generic = { cluster-size = 6 }
data-center-east = ${data-center-generic, name = "east" }
data-center-west = ${data-center-generic, name = "west", cluster-size = 8 }

[havocp]

We may be mixing multiple topics on one issue here, but the README proposes extending the string value concatenation to arrays and objects. So

${foo} "hello"

concats ${foo}'s value with "hello", with arrays

${foo} [1,2,3]

prepends ${foo} to the array, and with objects it would merge the two, so

${foo} { name = "east" }

would merge { name = "east" } into ${foo}

Anyway this would be a fairly natural extension of the existing implementation and spec.

[NicholasSterling]

That looks great, and yes, sorry for dragging this issue all over the place. :^)

[havocp]

I opened #3 for this other idea, let's leave this issue for the JSON render() mode.
Also, there's a "serializable" branch now that makes config objects serializable, will be on master soon.

[havocp]

I've now added ConfigRenderOptions. To get JSON you should be able to do value.render(ConfigRenderOptions.concise())

[ayush]

thanks

[adeshrd]

@havocp

Also, there's a "serializable" branch now that makes config objects serializable, will be on master soon.

The Config object doesn't seem to implement Serializable interface yet. Any plans for making it serializable?