Hi!
There are global services that all plugins need. Configuration
variables (and other variables in general) are a part of this.
The functionality should be in a base class for all functions. We
should stick with the namespacing rules... aka Foo plugin would then
have all of its variables be F_XXX.
The other sense of GLOBAL, meaning visibility is really an operation
of the plugin to decide (since some variables will always need to be
global in vision).
Cheers,
-Brian
On Jul 6, 2009, at 10:39 AM, Monty Taylor wrote:
Eric Day wrote:
Hi Monty,
Looks good! One suggestion I would have is to integrate this into a
top-level plugin object. So, instead of defining new globals in each
plugin, be able to extend a base plugin class (not to be confused
with
the specific plugin class types like StorageEngine/UDFs/...). The
variables could then be members of this plugin class, and we can
store other things in this class as well (like module dependencies,
configuration vars, ...). I'm just not a fan of introducing new
globals when they could be encapsulated by a core plugin class
type. The namespace prefix could also be defined in this class that
will be used for sysvars and future config.
So ... I think that the work global has gotten perhaps a little bit
overloaded here. Plugins shouldn't be introducing new "globals" from a
C++ perspective in any case. (or, at least, they don't have to do use
this system - I also can't stop them) I totally agree about wanting
ownership of these to encapsulated within the plugin class, but I
think
that's already done here?
On the other hand, from a SQL perspective, a plugin is quite likely to
introduce a new "global" in so far as things like "show global status"
and "show global variables" are concerned.
Now, whether the references to these GlobalVariable objects are stored
in a global list and then in a list per plugin, or in one global
list is
certainly an implementation detail we can work out... but at the end
of
the day that list of variables should only be holding references
anyway
(and is only useful for "show global status")
I think we're on the same page about registration via the plugin class
for automatic namespacing, etc.
I'll have my thoughts more organized and some examples later, but
just wanted to toss this out there.
Totally. I'm on vacation and not really here right now. :) But we
should
certainly chat about it.
Monty
On Thu, Jul 02, 2009 at 04:19:20PM -0700, Monty Taylor wrote:
http://drizzle.org/wiki/Refactor_system_variables
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
