On Sat, Mar 21, 2009 at 11:20:20AM -0400, Jay Pipes wrote:
> > * Easy to upgrade/modify the plugin APIs.
>
> Cool, but I'd like to hear more details about this...
If plugins are just extending an abstract class for that plugin type,
we can easily add new functionality via methods/members without
breaking backwards compatibility. No pre-defined struct mappings
or function argument lists that would break if you recompile an old
module with a new server header.
> > * Plugin/module dependency tracking.
>
> Sure, but I consider this a "phase 2" type thing...
Possibly, way may wait on this until we want to tackle runtime reloads
(the main reason why it is there). But something to keep in mind if
we are redesigning the interfaces now.
> > * Dynamic code upgrades while keeping state. For example, InnoDB could
> > keep the buffer pool in memory while the module was reloaded,
> > keeping the cache warm.
>
> Again, phase 2 type of thing. The reason I say this is because with the
> current code base (or any large project really) it's incredibly easy to
> go down a rathole and try to bite off more than what's feasible. My
> best advice would be to start small and slowly improve on the interfaces
> instead of a big-bang approach. Just some advice from what I've learned
> over the past 9 months... :)
Yeah, my thought is to provide the hooks and framework, but don't
actually act on them until we get around to it. It will be up to the
module to do what it wishes, so as a first pass, it could just do
nothing (like the do today).
> > * Easier to stack, skip, or replace core modules within drizzled.
>
> Could you be more specific on what you mean by "stack"? Do you mean a
> module which builds on top of another, or do you mean a "module
> registry" which allows you to push and pop modules in a stack-like way?
This is mostly with the dependency tracking. For example, having a
common module that other modules may depend on. If we break everything
out into modules like I mentioned at the end, then we'd have a core
runtime module and a chain of dependencies along the way.
> Hmmm, ok. Sounds like what you want is a callback which allows the core
> to ask the module to provide the core with a vector of configuration
> variables when loaded. To do this, really we need to rework the way
> that "system variables" are constructed and queried in the core.
Yup.
> Right now, system variables are stored in a map<>, and each system
> variable is a derived type from sys_var (see drizzled/set_var.cc).
> Plugins can register a system variable with the DRIZZLE_SYSVAR_{TYPE}
> macros in drizzled/plugin.h but the system is quite difficult to
> understand internally. I like your idea of having module configuration
> variables loaded when the module is actually loaded (and not before),
> but I'm not sure what you mean by "able to remove the built-in plugin
> list". Could you expand on that?
sql_builtin, which is needed to query the possible options to print out
a help menu. Instead this should be dynamic (scan module directories).
> I think it would be useful for a module to be able to tell the drizzled
> core where it might find configuration files for the plugin, and even
> have the drizzled core by default look in a section named for the plugin
> in the main drizzled configuration files, too.
I was thinking of having sections in the main config file, but we
could easily add a 'include' directive into the config file parser
if we want to break those out.
> > Module Loader
Sounds like you were making something else to look at, so I'll wait
until then to comment on the idea you mentioned. I'm worried about
the void * though. :)
-Eric
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
