From: Matthias A. <mat...@gm...> - 2014-09-15 07:40:43
|
Am 10.09.2014 um 10:47 schrieb Martin Koeppe: > So "sslcertck" and "sslfingerprint" must be repeated over and over. > Also if one server doesn't support ssl at all, it's even worse. I > can't specify "ssl" in defaults section, because there is no (or at > least not to my knowledge) no-ssl keyword, which I could apply to all > user accounts on that server. So instead I added "ssl" to every user > account on every other server, just because one server doesn't support > it. "sslcertck" is the same. I thought I had checked for missing no-* options but apparently I missed those. These might even be 6.3.X stuff depending on how complex the fix will be in code, I will check that. > IMO all these SSL related options should be server options, not user > options, as they apply before any user name is transmitted to the > server, so there should be no need have it configured differently for > every user. Ok, the server could behave diferently after user logon > depending on the previously negotiated connection. But then I could > have 2 different poll sections for the same server. I have always wondered if we should be adding some notion of scope to settings, but this would then have to go along with parenthesizing (perhaps using curly braces) of some form, perhaps apply defaults ... to ... end defaults statements. Sooner or later I will have to rewrite the bison parser because it invariably must leak memory and has some minor quirks, but have not decided on a solution. Lemon (from sqlite3's author) is one option, going for C++ with Boost::Spirit that follows a strict full resource tracking through objects is another, and there are surely more solutions. This will entail a parser rewrite and might be a good point in time to specify such extensions. (Bison recommends to consider garbage collection, but I'm not sure that it's the right approach, it can lead to apparently nondeterministic timing behaviour.) Thanks for your suggestions! |