Hi!
On Aug 3, 2008, at 6:10 AM, Brian Aker wrote:
So I am hacking out an example auth plugin at the moment.
What sort of naming structure/directory structure do we want longterm?
Right now we have "storage" and then "plugins"
I'd vote for having one plugins dir that contains everything that can
be loaded at runtime.
IMHO it should contain the actual plugins code grouped by their
purpose/API they use and that structure should be mirrored in the core
sources.
E.g.:
plugins/
auth/
pam/..code..
storage/
...
parser/
...
drizzled/
plugins/
auth/
"auth_plugin.h" (or similar)
...
I do not care for it. We do not need to fix this up right now, but
if anyone feels strongly about how we will handle this, I would love
to hear.
The above would make it easy to tell which parts can be extended and
where to find the API for doing so, instead of hunting through a huge
pile of source/header files in one directory.
Maybe the individual plugin dirs should have a more verbose name to
disambiguate them visually, I don't know if that helps. Name-wise, I
think the libraries should then be
plugin_<category>_<name>.<your_favorite_shlib_ext>
Might be helpful to think about plugin "bundles" that load multiple
individual plugins all at once, but maybe it's not so crucial.
cheers,
-k
--
Kay Roepke
Software Engineer, MySQL Enterprise Tools
Sun Microsystems GmbH Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfang Engels, Dr. Roland Boemer
Vorsitz d. Aufs.rat.: Martin Haering HRB MUC 161028
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
