On Fri, 2011-04-01 at 19:30 -0400, Matthew Barnes wrote: > > I think the flags approach is fine. > > Long as you're breaking ABI (which is perfectly okay right now), you > might consider combining the 'try_empty_password' and 'needs_password' > booleans into a single CamelServiceAuthFlags enum to future-proof the > ABI a little.
Thanks for the feedback. In fact, on closer inspection of how I'd actually implement this in the camel-sasl-ntlm code, I see I'd end up with something like this in camel_sasl_ntlm_class_init() to override the try_empty_password flag if the helper seems to be available: #ifndef G_OS_WIN32 if (!access (NTLM_AUTH_HELPER, X_OK)) camel_sasl_ntlm_authtype.try_empty_password = TRUE; #endif I don't like that much; I think I'd prefer to have a new method in the CamelSaslClass, and a corresponding camel_sasl_can_empty_password() method. That way, we can actually try spawning ntlm_auth at the right time and see if it *currently* knows our password. Never any need to restart Evolution to get the newly-installed auth helper to be noticed, no false positives when it's *present* but doesn't know the password, etc. That makes it slightly more fun in the provider code, but not much. Will look at that and post a revised RFC patch later today, when I have more that one hand. -- dwmw2 _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers