Anshu, Henrik, Let's put the issue of a reload function aside for the moment because I think we're getting ahead of ourselves.
The first priority of this project is to make variables dynamic. So we (or, primarily, Anshu) should begin with making regex_policy.policy dynamic, properly scoping the code, testing it, etc. Even though SET GLOBAL regex_policy_policy=@@regex_policy_policy is not the ideal, it works as a method to reload the value (in fact, it works intrinsically; one would have to specifically code the plugin to make it not work as a reload method). So let's just accept this method until we're ready to implement a real reload function, which we should research more and discuss in another thread. -Daniel Le 1 mai 2012 à 14:12, Henrik Ingo a écrit : > Yes, doing both is probably a good option. > > The argument for not doing both would probably be a desire for more > simplicity, a bit of the thing Apple does well and Gnome (in my > opinion) less well. In that case you would argue it is in fact user > friendly to only provide one command - "reload configs" - that takes > care of everything / all plugins. In practice the user is probably > changing config for some particular plugin, so reloading all configs > is unnecessary, but I don't actually see it as a problem either. > > henrik > > On Tue, May 1, 2012 at 10:09 PM, Anshu Kumar <ansharyan...@gmail.com> wrote: >> Hey Henrik, >> Thanks for the quick reply. >> Regarding your last suggestion (Reload configs), I assume this can be done >> by having a local reload function for every plugin first and then if >> everything goes fine, it can be implemented using universal command. From >> user perspective too, if he wants to reload some specific plugin, he will >> just have to call the reload function prior to the particular plugin. >> Additionally, if he wants to reload all the configuration, he can flush all >> the configs and reload with the new ones using the universal command. >> Is there something I am missing? >> >> On Mon, Apr 30, 2012 at 1:06 PM, Henrik Ingo <henrik.i...@avoinelama.fi> >> wrote: >>> >>> Anshu, I'd say that changing the value of regex_policy_policy should >>> automatically cause the file to be read. >>> >>> Regarding a function, there are 2 ways. >>> >>> A simple way is that each plugin that can reload something, implements >>> its own function to do so. We should encourage some common naming >>> pattern. Example: >>> >>> SELECT regex_policy_reload(); >>> >>> (Note that we don't support CALL functioname() syntax, might be a good >>> time to add it now.) >>> >>> Another way, as you suggest is to add a universal command to reload >>> everything. For instance, we already support the syntax "SHUTDOWN;". >>> This could be implemented in a similar way. Example: >>> >>> RELOAD CONFIGS; >>> >>> To make a universal command work, all plugins that can reload >>> something should subscribe to receive reload events from some API. I >>> assume this API needs to be implemented, or at least some "reload" >>> event must be added to an existing API. This is an area of server >>> internals I'm not familiar with. >>> >>> The latter is of course preferable design. Now that this has become a >>> GSoC project and not just low-hanging-fruit, you should consider it. >>> As proof of concept you can of course implement regex_policy_reload() >>> too (most of the code would still be re-used for the listener in the >>> universal solution.) >>> >>> henrik _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : drizzle-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
