Let's move this discussion about the best way to configure geode off of this thread about the client protocol.
I do agree with John that we should move away from xml. Right now if I add a new configuration option I have to: - add it to the java API - Add it to the xsd - write code to do xml parsing and generation - write code for a gfsh command - write code to update cluster configuration This turns what should be a 5 minute task into 5 days. How can we get to the point where we just define a new configuration option in one place? -Dan *Properties* are simple (think *Spring Boot; *there is no better example); > > YAML provides structure (with IDE support); > > *Type-Safety* is the responsibility of the framework/API (think the > configuration format really should not matter, but data-binding/conversion > is always a concern regardless of the configuration format, like > validation, which should not be expressed/enforced with in the XSD, and > simply cannot be enforced when property placeholders are supported (a very > useful and powerful configuration option) in XML since the type would > necessarily be constrained to xsd:string in that case). > > Again, I emphasis that adding Properties should be done with care as it > increases the "surface area" and complexity of any public API (yes, > configuration Properties are part of the public API). Properties are also > only suitable for simple configuration attributes (like a port). > > When complex configuration is needed, there is not better option than > providing adequate API support with right abstractions, hence 1 of the > reasons *Spring* is moving away from XML (which can get overly verbose) to > Java config. > > -j
