Yes to API first, config file second! Config file should reflect the API and domain objects.
But... How can you even begin go argue properties over XML? Configuration should be well structured and expressive. Properties is neither. Properties can't handle collections of things without some serious ugliness. server.connectors.0.name = "my connector" server.connectors.0.port = "1234" server.connectors.0.someConfig = "true" server.connectors.1.name = "my connector" server.connectors.1.port = "1234" server.connectors.1.someConfig = "true" This isn't at all well structured or even that readable. Doesn't have built in support for duplicate protection: somthing.name = "my name" .... something.name = "OOPS" No type safety: my.timeout = "yes please" If I am configuring with XML and a schema my editor will warn me about such mistakes before I hit the runtime. None of the other mentioned formats can do that. In the list of configuration file formats properties falls nowhere on that list. XML takes the cake because of the type safety from schema support. YAML lacks type safety and schema but can at least express collections. JSON ugly syntax, lacks type safety and schema, but supports collections. Sure XML has its shortcomings but I would love to hear why properties is better in your opinion. <cents>2<cents> -Jake On Mon, Oct 2, 2017 at 12:57 PM John Blum <jb...@pivotal.io> wrote: > I don't mean to derail the topic at hand, but... > > On the same vain as Properties, can we also stop talking about XML? I much > prefer Properties over XML any day, especially given YAML. However, that > does not imply Properties should be added at will. Properties also > increase the "surface area" of the public API as well. > > Also, the API and XML are not on even plane; not even close. > > IMO, the API should be the primary means to configure a feature; all other > configuration options are secondary and optional (as needed). > > Therefore, given an API-first approach, the other configuration formats and > options become more apparent (providing the API was designed with the right > abstractions in the first place). > > $.0.02, > -j > > > > On Mon, Oct 2, 2017 at 12:18 PM, Dan Smith <dsm...@pivotal.io> wrote: > > > One thing to think about - if the new protocol doesn't support two-way > > authentication maybe we should throw an exception if the user sets > > ssl-require-authentication=true? We definitely don't want to lie to > > the user and pretend that we are providing some level of security > > which we are not. > > > > I'm assuming the new protocol will also need to read the ssl-ciphers, > > ssl-protocols, ssl-keystore and ssl-truststore settings. > > > > -Dan > > > > On Mon, Oct 2, 2017 at 12:08 PM, Anthony Baker <aba...@pivotal.io> > wrote: > > > Is there a need for property yet? > > > > > > The authentication-enabled question could be answered from the existing > > security properties. That ensures consistency and means a user would > only > > need to set a single switch. > > > > > > If we only support a single authentication mode, we can defer adding > > configration until we need it. > > > > > > Anthony > > > > > >> On Oct 2, 2017, at 11:56 AM, Galen O'Sullivan <gosulli...@apache.org> > > wrote: > > >> > > >> Currently, we have a setting for the new client protocol that controls > > >> whether authentication is required or not. We expect to expand this in > > the > > >> future, and also that there may be more configuration options for the > > >> protocol. We would like to namespace the settings for this protocol > but > > >> don't really have a good name for the protocol. > > >> > > >> We're expecting to do configuration via gemfire.properties -- I hear > > that's > > >> the right place to put these things. It looks like the setting would > > take a > > >> form like `geode.new-client-protocol.authentication-mode`. "New" > client > > >> protocol is not a good name because it will be outdated before long. > > It's > > >> not the only client protocol, so "client-protocol" would be > misleading. > > Any > > >> other ideas? > > >> > > >> Thanks, > > >> Galen > > > > > > > > > -- > -John > john.blum10101 (skype) >
