*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 On Mon, Oct 2, 2017 at 1:36 PM, Swapnil Bawaskar <sbawas...@pivotal.io> wrote: > As a geode admin setting up the cluster with security, I don't want to > worry about what version of protocol the client is going to use. > +1 for the new protocol to just use existing properties. > > On Mon, Oct 2, 2017 at 1:24 PM Dan Smith <dsm...@pivotal.io> wrote: > > > I realized I've been assuming you were asking about turning on ssl > > authentication. Maybe you are talking about authenticating with the > > security manager. Either way, what Anthony said still applies - the > > new protocol should just use the existing properties (security-manager > > in that case). > > > > -Dan > > > > 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) > > > -- -John john.blum10101 (skype)
