Last night I created https://blueprints.launchpad.net/drizzle/+spec/plugin-standards and proposed to merge lp:~daniel-nichter/drizzle/uniform-plugin-names. Long story short: we have to use DRIZZLE_DECLARE_PLUGIN for the time being. Using just DRIZZLE_PLUGIN and all metadata in plugin.ini will require more extensive and significant changes, so for the moment I just want uniformity no matter the method. Later we can change things easily because now there is uniformity. I will blog later what I learned about the plugin system to explain why DRIZZLE_DECLARE_PLUGIN is needed.
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 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. 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? -Daniel Le 5 janv. 2012 à 12:29, Henrik Ingo a écrit : >> Does anyone else have an opinion on this? I'd like to change this while in >> the process of making plugin names uniform (see my original email in this >> thread). >> > > It's not based on any technical consideration one way or another, but > for me I would intuitively search in plugin.ini which is a central > file with information about the plugin. In the other scenario, > consider that a plugin may have many source files, yet only one of > them will contain DRIZZLE_DECLARE_PLUGIN and I can't always know which > file has that info. Always having it in plugin.ini sounds like good > housekeeping. > > Like you listed below, either way you won't get rid of plugin.ini, > since it contains build related data anyway. > > henrik > > On Thu, Jan 5, 2012 at 8:02 PM, Daniel Nichter <[email protected]> wrote: >> For example, in slave/plugin.ini: >> >> sources=module.cc replication_slave.cc queue_thread.cc queue_consumer.cc >> queue_producer.cc sql_executor.cc replication_schema.cc >> headers=replication_slave.h queue_thread.h queue_consumer.h queue_producer.h >> sql_executor.h replication_schema.h >> libs=${top_builddir}/libdrizzle-2.0/libdrizzle-2.0.la >> >> Other plugins have that kind of stuff too. It seems DRIZZLE_DECLARE_PLUGIN >> can't accommodate that. So I would vote for putting everything in >> plugin.ini and using only the minimal DRIZZLE_PLUGIN. If we change plugin >> systems, then hopefully it will either be compatible with the existing >> plugin.ini files or we can just write a script to convert the well-formatted >> plugin.ini files. >> >> So to summarize the debate: >> >> 1. There's two plugin interfaces DRIZZLE_PLUGIN and DRIZZLE_DECLARE_PLUGIN >> 2. The short one (DRIZZLE_PLUGIN) puts all metadata in plugin.ini (author, >> version, etc.) >> 3. The longer one (DRIZZLE_DECLARE_PLUGIN) puts some metadata (author, >> version, title) in the source code but other metadata (sources, headers, >> libs, etc.) must still be in plugin.ini >> 4. Brian favors the longer one because "projects churn module/plugin API's >> with some frequency. Keeping it in source makes it easy to port to whatever >> the current flavor of interface is without much effort." >> 5. I (and Andrew) favor the the shorter one to centralize all metadata in >> one place, plugin.ini >> >> Does anyone else have an opinion on this? I'd like to change this while in >> the process of making plugin names uniform (see my original email in this >> thread). >> >> -Daniel >> >> Le 15 déc. 2011 à 15:20, Henrik Ingo a écrit : >> >>> On Thu, Dec 15, 2011 at 5:37 PM, Daniel Nichter <[email protected]> wrote: >>>> Is it possible to put everything in the source file? >>> >>> It depends what you mean by "everything". Most of the stuff in a >>> plugin.ini file is consumed by config/pandora-plugin for its own >>> purposes (it creates autoconf input files for us). The author and >>> module name fields go into drizzled/plugin.h, where you'll see two >>> familiar macros: >>> >>> #define DRIZZLE_PLUGIN(init,system,options) \ >>> DRIZZLE_DECLARE_PLUGIN \ >>> { \ >>> DRIZZLE_VERSION_ID, \ >>> STRINGIFY_ARG(PANDORA_MODULE_NAME), \ >>> STRINGIFY_ARG(PANDORA_MODULE_VERSION), \ >>> STRINGIFY_ARG(PANDORA_MODULE_AUTHOR), \ >>> STRINGIFY_ARG(PANDORA_MODULE_TITLE), \ >>> PANDORA_MODULE_LICENSE, \ >>> init, \ >>> STRINGIFY_ARG(PANDORA_MODULE_DEPENDENCIES), \ >>> options \ >>> } >>> >>> According to grep this is the only place where PANDORA_MODULE_AUTHOR >>> appears, didn't check the others. >>> >>> >>> So it seems Drizzle supports both of, and code comments do not decree >>> or deprecate either one of, the following: >>> >>> - Module meta data (author, name, title, version, license) is >>> specified in plugin.ini. In the c++ source you can omit them by using >>> the shorter DRIZZLE_PLUGIN macro. >>> >>> - Module meta data is specified in DRIZZLE_DECLARE_PLUGIN macro, and >>> you can omit it from plugin.ini. >>> >>> >>> henrik >>> >>>> If not and we're stuck >>>> with plugin.ini files, then we'll have to port that info in any case (if >>>> the >>>> plugin API changes), so porting a few extra lines doesn't seem bothersome, >>>> especially if all the info to be ported is in one file with a common >>>> format. >>>> My other reason for preferring the plugin.ini file is that it's slightly >>>> easier to parse. >>>> >>>> -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
