I think that custom, pluggable type of guardrail will be a great addition to the framework.
The first guardrails prototype included a factory of guardrails that was able to provide different guardrail instances depending on the specified class and client state. That was discarded during review in favour of a pluggable provider of guardrail configurations, so the guardrail instances are always the same but the source of configuration can be customized. That allows to provide different configurations for different users with minimal hassle. Although that works for most of the guardrails, it doesn't give the kind of flexibility than the ability to plug custom guardrail implementations does. I think that the proposed approach for making specific guardrail implementations pluggable allows us to keep the simplicity of the current approach while also giving us flexibility for particular cases like password validation. The generic CustomGuardrail that will be added to the framework should ease (and standardize!) validation pluggability, so I think it can be useful in the future. On Mon, 19 Sept 2022 at 12:27, Miklosovic, Stefan < stefan.mikloso...@netapp.com> wrote: > Hi list, > > together with my colleague Jackson Fleming we put together CEP-24 about > password validation and password generation in Cassandra. > > https://cwiki.apache.org/confluence/x/QoueDQ > > We are looking forward to discuss this CEP with you in depth. > > The outcome of this thread would be to sort out any issues / concerns you > have so we might eventually vote and implement that in upstream if our > contribution is found to be useful. > > There is a reference implementation provided we would like to build our > solution on top. > > Regards > > Stefan Miklosovic >
