> difficult to pull off and requires productization, in other words not low-level tooling in a text file.

Is this supposed to be a feature? One of the great things about simple config files is that you can use standard GNU tools to view edit, and diff them, you can put them in source control, you can be sure that you can edit them on a remote server no matter what's installed, etc.

Eliminating all those benefits would require an extraordinary jump in functionality as a tradeoff, a jump in functionality that most things frankly don't need.

You're right regarding the value of text files. ConfigNode is really for management of configurations for use cases where you can have huge JSON/YAML files and you want to be able to manage them, facilitate dynamism (often using templates)...support collaboration..etc...it is a gold-plated solution and not necessarily suitable for simpler needs.

Here's another example of ConfigNode used to manage Akamai configurations:

https://youtu.be/gcPAmpKo9fs

Akamai configurations can be very complex and need to be maintained and managed, you can't really do that effectively using text files.

I worry that text files promote local minimums. Like, the standard GNU tools or whatever editor you use is "good enough" for what you expect to do with them, but there exist better tools for your specific task that you never even look for.

With a binary file, you of course have to be using something specific to work with them. And if lots of people were doing that, that would in turn drive a lot of specific, good options to choose from. The tools would be better at their specific task. They could provide actual _user interfaces._

But there's not enough standardization in user interfaces for to reduce the cost of relearning each tool, and the tools would need both an interface and an API to automate them (we don't tend to get both for free), and we don't have anything great for chaining together APIs. So text files it is, which kind of provide these things, but they don't extend too well.

The trend in computing tools is to slowly invent what you could get easily with more specific formats... using text files. Automatic formatters, so you can pretend your project files are really the AST you care about. Smart IDEs with autocompletion, because you're not really typing arbitrary characters. IDEs that will collapse a lot of unnecessary information for you, like showing only the first snippet of JSDoc. Type systems that show you what's available and what you can plug together in a sane way. Version control that pretends it knows how to solve the problem of diffing/merging.

The answer is a marketing website with market-speak all over the page and 'Executable not found "/eula"' when trying to read Terms and Conditions?

Edit: I actually did download whatever this thing is. What is this thing? The README is Jetty's README. There are dozens of dirs with crap^W code in them.

It really is an answer to YAML/JSON, surely.

> the "So Much More" button is a link to the docs:)

Yeah... No. It looks like a link to yet more marketing-speak, and the page it links to answers zero answers as to why I would ever want it.

Hiding the product README in some nested folder in the source code is also a brilliant idea.

So, nope. I’m sticking to my YMLs and EDNs.

You had me at EDN

I am afraid your own cynicism (warranted or not) might be really blinding you here...I am not sure whether to feel proud of myself when my writing is designated "marketing speak" :)

The documentation link LITERALLY shows how to use the product.

Nothing is hidden, if you read the platform docs (http://codesolvent.com/doc/webapps/) you see it says:

"Solvent is an integrated platform that combines an application container (jetty), a middle-ware and a developer environment to provide a complete solution for delivering web applications."

ConfigNode is something you'll put on a server as a config management environment, the output can be json/yaml/xml..etc

I think you might find it quite unique if you just give it a chance (no marketing) :)

> Solvent is an integrated platform that combines an application container (jetty), a middle-ware and a developer environment to provide a complete solution for delivering web applications.

Bingo.

> ConfigNode is something you'll put on a server

I’ll never put it on a server for very obvious reasons

I recommend changing "So Much More" to "Documentation" or something. I had no idea that was a link, let alone a potentially useful link.

That link is pretty terse. I have no idea what "object graphs" are in this context nor how they solve the "endless iteration on the right config format" problem. Moreover, churn on config file formats is probably the least of my dev problems.

"object graphs" means exactly what it typically means...ie objects composed of other objects.

The key is that you have to have a way to create such graphs beyond code (ie new Resource({"attr":value}..)).

Text file formats are always going to be an issue the moment your requirements are complex.

Here's another example of what I am referring to:

https://youtu.be/4yepPOznakk

YAML and JSON already represent object graphs. This appears to be essentially a config file editor, not a superior configuration format. It has a GUI for creating or editing a config, and then it outputs YAML or JSON or XML.

It can be hard to fully convey how ConfigNode works without actually showing it in action. Yes it does give you a UI environment to edit the object graph and outputs YAML/JSON/XML..etc.

However the output comes after evaluating the object graph. In other words it doesn't just reassemble a bunch of static values but rather actually executes objects (think POJOs) to produce the fields that make up each object.

Trees are not graphs. You have to un-circularize your objects before stringifying.

It's true that you need to remove cycles before you can create a tree, but acyclic graphs are still graphs (and most relevantly they're probably the kind of graph you want your config to be). And YAML actually can contain cycles, so even if you only want to consider cyclic graphs, YAML still qualifies.

Yes, that’s what I meant.

Trees are always graphs. A tree is a an acyclic graph with a node designated as root.

You can have unrooted trees. See the second paragraph at https://en.wikipedia.org/wiki/Tree_(graph_theory)#Rooted_tre....