+1 for removing it. We should be using opaque pointers to reduce/eliminate ABI versioning issues anyway.
Plus, has anyone looked at using GLib's GModule for a lot of the stuff that is handled in sql_plugin.cc? I know I keep harping on GLib, but GModule provides some very nice features: * Entirely cross-platform (only dependency is dlopen() which most systems nowadays have * Plugins can have their symbols loaded either into the global name space or locally (this solves differently versioned, but similar plugins, as symbol name collisions won't happen * The plugin's symbols can either be loaded into the address execution space as needed, or upon initialization (this gives us and plugin writers the flexibility of deferring infrequently used plugins for lazy initialization and reducing startup costs for loading many plugins) * g_module_make_resident() allows protection to avoid unloading of system plugins, if the plugin implements mission-critical functionality -jay Mark Atwood wrote: > in server/sql_plugin.cc > > there are three arays, min_plugin_info_interface_version, > cur_plugin_info_interface_version, and > max_plugin_info_interface_version, and then the plugin structure > declares a "version" as it's very first integer member. > > In theory, this is so that MySQL could version the plugin ABI, and allow > a range of versions. > > In practice, this never worked, and probably never will. There is no > point in versioning our ABI until we have an ABI other than "the whole > server". > > I want to rip it all out. It will make the plugin system simpler, > remove code that adds no value. > > What say you all? > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
