Le 18 janv. 2012 à 09:52, Henrik Ingo a écrit : > >> 1. Module names must match [a-z_]+. E.g.: auth_all, slave. etc. > > Why no numbers? What if I want to develop ext3_autotuner module?
Good point. This item has been updated accordingly. >> 2. Modules must use DRIZZLE_DECLARE_PLUGIN > > As discussed, this is the solution that works for now. (Long term, I > would support making plugin.ini the place that keeps most information, > when current problems are fixed.) > > Btw, from your distincion of modules vs plugins, shouldn't this macro > be called DRIZZLE_DECLARE_MODULE? I get the impression one module can > contain many plugins, correct? If it's not too painful, I might changed PLUGIN to MODULE because you're correct: it's more accurate. Also, I was thinking that we need to make this distinction clear in the docs, too, else people will see D_D.MODULES and MODULE_NAME in D_D.PLUGINS and wonder wtf? Also, it's important to know that although we can talk about the syslog() function plugin, and error messages to syslog, both of those plugins are provided by one module: syslog. So you have to --plugin-add=syslog to get either or all. Granted, this suggests would should change the --plugn-* options, too, to --module-* but that might be too much. If it's clear in code and documentation, that's sufficient I think. >> 8. If not #6 or #7 then: >> >> 8.1. Plugin names must match [a-z_]+. >> >> 8.2. If not a Function plugin and there is or might be several types of the >> plugin, use the naming scheme <type>_<thing>; for example: > >> file_query_log >> csv_query_log >> syslog_query_log >> default_replicator >> filtered_replicator >> user_policy >> regex_policy > >> query_log, replicator, and policy are standards "things" of which there are >> several types: file, csv, syslog, default, filtered, user, regex. Although >> a user can select plugins based on PLUGIN_TYPE, this also allows WHERE >> PLUGIN_NAME LIKE "%_query_log" to see all types of query log plugins loaded. > > Note that authentication plugins do not conform, they are currently > auth_all, auth_ldap, auth_schema... You can then of course do LIKE > "auth_%" > > I think type-thing works in some cases where it makes the plugin name > sound natural (ie user_policy and not policy_user). Otoh, having > thing-type would group similar plugins together when sorted > alphabetically: all auth_* plugins start with "a", all log_* plugins > with "L", etc... I consider this a significant advantage when people > will do things like SHOW VARIABLES (without additional filtering). > > Either way would require renaming of existing plugins, I'm not sure we > really want to do that anymore. But a rule could of course be forced > for new "things". Exactly. I tried renaming all plugins both ways, user_policy vs. policy_user, but only the auth plugins are "backwards" so I didn't want to change the majority. As you noted, this means one has to do "%_policy" rather than "policy_%" and also that multiple policy plugins don't appear side-by-side if sorted, but users can still order by plugin type. And the auth plugins will just have to remain the exception. >> [snip] >> >> 13. Plugins must have an option called "disable" to allow loading and >> configuring the plugin but disabling it (so once Drizzle is started, >> <module>_enabled=FALSE). This is in case the user wants to enable the plugin >> (see #11) later, after starting Drizzle. If the user does >> --plugin-add=<module> they obviously want the module/plugin, and in the >> normal case they probably want it enabled & working once Drizzle starts, so >> an extra --<module>.enable option would be redundant/extra work, and having >> to do SET GLBOAL <module>_enabled=1 would be similarly redundant. The >> special case is noted here: the user wants the plugin, so they add and >> configure it, but they don't want to use it immediately. So having to do SET >> GLOAL <module>_enabled=0 is would also be redundant/extra work, whereas the >> special case is handled cleanly without extra work by --<module>.disable on >> the cmd line. (Also, rather than "disabled", "disable" fits better with >> "add", "remove", and "load".) > > > I'm not at my Linux box now, but if I remember correctly, our > ./configure supports options > ./configure --with-plugin-<module> --disable-plugin-<module> > where the plugin is built but not loaded on startup. (until you then > do --plugin-add) > > I find it as possibly confusing that your --<module>.disable has a > different meaning. Otoh I can't think of a better alternative. (If > anything, the configure option should be renamed to something like > disable-load-plugin.) I've thought more about this and looked at the modules to see what the real current situation is and I will comment in my next email (in reply to your next email). Short version: I've removed #13. -Daniel _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
