Various components have a SASLMechanisms collection for handling SASL logins, but they also have separate Username/Password properties for handling legacy non-SASL logins. It can be confusing to know which credential properties to use for which scenario, so the legacy properties should be deprecated and replaced with a new UserPassProvider property that shares a TIdUserPassProvider with the SASLMechanisms. This way, everything can be centralized. For backwards compatibility, have the legacy properties create an internal TIdUserPassProvider if no provider is assigned by the user.
Various components have a
SASLMechanismscollection for handling SASL logins, but they also have separateUsername/Passwordproperties for handling legacy non-SASL logins. It can be confusing to know which credential properties to use for which scenario, so the legacy properties should be deprecated and replaced with a newUserPassProviderproperty that shares aTIdUserPassProviderwith theSASLMechanisms. This way, everything can be centralized. For backwards compatibility, have the legacy properties create an internalTIdUserPassProviderif no provider is assigned by the user.