On Mon, Jan 16, 2012 at 8:26 PM, Daniel Nichter <[email protected]> wrote: > Last night I created > https://blueprints.launchpad.net/drizzle/+spec/plugin-standards and proposed > to merge lp:~daniel-nichter/drizzle/uniform-plugin-names.
Wow, that was a lot of thought gone into one blueprint. > 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? > 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? > 3 Modules most not use name, title, description, version, author, or license > in plug.ini. I.e. do not duplicate metadata between DRIZZLE_DECLARE_PLUGIN > and plugin.ini > 4. Modules most not use DRIZZLE_PLUGIN. Agree. > 5. Module short descriptions must be either a noun phrase without a leading > article, e.g. "RAND funcion" or "MyISAM storage engine", or an infinitive > phrase, e.g. "Logs queries to a file" or "Publishes transactions to ZeroMQ". Ok. Note: "Log queries to a file" would then be prohibited. > > 6. TableFunction plugins are automatically named <SCHEMA>-<TABLE>, so other > plugin names most not use hyphens (-). > > 7. StorageEngine plugin names most be CamelCase, e.g. "FunctionEngine", or > all uppercase, e.g. "MEMORY". > > 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". > 9. Plugins must use their own space according to > http://wiki.drizzle.org/Coding_Standards#plugins > > 10. Plugins must allow Drizzle to start if loaded with only > --plugin-add=<module_name>. Plugins can warn and disable themselves if some > necessary config isn't set, but... > > 11. Once loaded, it must be possible to dynamically enable and disable > plugins entirely by doing SET GLOBAL <module>_enabled=TRUE|FALSE, presuming > its configed properly. (Also, rather than "enable", "enabled" reflects the > plugin's status, e.g. "Is the plugin enabled?" "What's the status of the > plugin? It's enabled.") Therefore... > > 12. Plugins must have a variable called "enabled". Although, if the plugin > isn't configured properly, it should still load (see #10) but set itself > enabled=FALSE (and probably warn). > > 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.) > 14. Other features of a plugin should also have <feature>_enabled variables > and disable-<feature> options, e.g. > --query-log.disable-file/query_log_file_enabled=TRUE|FALSE. This in > combination with #13 allows a user to load a module but only use some of its > features. E.g. "--plugin-add=syslog --syslog.disable-logging" if the user > only wants to use syslog for error message logging. > > 15. All plugin variables must be dynamic (in addition to #11). With the last points there is still some work to do :-) > In the mean time, I would like feedback on the blueprint. I think going > forward it's critical to standardize modules/plugins because they are the > arms, legs, and torso of Drizzle (the kernel being the head and brain, of > course). Unfortunately for users, no two plugins are alike. Not only do > they behave differently, their options show no sign of standardization, and > all but query_log and auth_schema are _fully_ dynamic. > I agree and your effort here is laudable. > I think standardizing the modules as per the blueprint will reduce the > learning curve for new users because even if there's 70+ modules, they will > have a consistent look-and-feel. > Not to mention making the code ever more maintainable. > My one big question concerns the reasoning in item #13: should plugins be > "all on" by default, or "all off" requiring the user to turn on what they > want? I tend to think "all on" because most plugins only do one thing so if > the user adds it, they want it to be working now. The argument for "all off" > is in cases like syslog which do multiple things, or perhaps query_log which, > if configured badly, may come on and start hammering the disk. I think the > 95% case is "all on". What do you think? > I will get back to this in the next email. henrik -- [email protected] +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
