Regarding what I labeled the simplest solution below, SslConfigs could instantiate the custom interface only if the yet to be validated configs were passed in to the call to get the list of known SSL configs.
-----Original Message----- From: Pellerin, Clement Sent: Tuesday, September 10, 2019 11:36 AM To: dev@kafka.apache.org Subject: [EXTERNAL]RE: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible Another solution could be a new standard ssl config that holds a list of extra custom configs to accept. Using a custom SslEngineFactory with custom configs would require setting two configs, one for the class name and another for the list of custom configs. In SslConfigs, we see that declaring a single config takes 5 values, so I'm not sure how it would work exactly. We could also declare a new interface to return the list of custom ssl configs and the extra standard ssl config I'm proposing holds the name of the implementation class instead. The reason a different interface is needed is because it would be instantiated by SslConfigs, not SslFactory. This seems the simplest solution. Anyway, the point of this exercise is to prove an acceptable solution for custom configs is not affecting the public API in KIP-519. -----Original Message----- From: Pellerin, Clement Sent: Tuesday, September 10, 2019 9:35 AM To: dev@kafka.apache.org Subject: [EXTERNAL]RE: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible Custom config is a term I invented to mean a config that does not exist in Kafka but is specified by a custom implementation of SslEngineFactory. The problem with custom configs (as I remember it) is that the list of configs is static in SslConfigs and config names are checked before SslFactory is created. ==> You must solve this problem because that is what killed KIP-383 and therefore is the sole reason why KIP-519 exists. ==> Your KIP does not have to implement the solution since it can be done in a future KIP, but your KIP must be compatible with the solution found. ==> A method to return the list of configs would help. This cannot be a static method in the interface since it cannot be overridden. ==> You could require a static method in the implementation class by convention, just like the constructor you require. This email did not originate from inside Information Builders.
