Make plugin registration object and registration methods

Registered by Jay Pipes on 2008-10-21

Make plugin registration object and registration methods

Blueprint information

Status:
Complete
Approver:
Brian Aker
Priority:
Essential
Drafter:
Brian Aker
Direction:
Approved
Assignee:
Monty Taylor
Definition:
Approved
Series goal:
Accepted for trunk
Implementation:
Implemented
Milestone target:
milestone icon cirrus
Started by
Jay Pipes on 2008-11-20
Completed by
Jay Pipes on 2009-04-19

Sprints

Whiteboard

Global Singleton- Plugin_regsitry

To add plugin:

  Plugin_registry::load_plugin(plugin_name)

    dlopens file

    call dysym(initialize), passing in reference to Plugin_registry

    initialize calls Plugin_registry::add(Plugin *)
      Plugin_registry now owns the Plugin *

    Plugin_registry::add returns a reference to the Plugin object it just stored

    the returned plugin object may then be used to perform plugin registration
      actions.

      /* Plugin registration and plugin registration actions are separated so
         that we can keep the management of the lifecyle of the plugin separate
         from the lifecyle of the services the plugin provides
       */

To add a new plugin type:

  Add a virtual method to Plugin that can be

  Add a subclass of Plugin_registry

Typing:

  Plugin_registry

    Function_plugin_registry

  If you want to do plugin_foreach(DRIZZLE_UDF), instead do:
  Function_plugin_registry::foreach()

  This goes away... plugin_foreach should die, because each plugin type should be injecting into a type-specific registry. For instance, you don't need to foreach the plugins to find a UDF - you just ask the Function_registry for a function name "foo" ... the cost of list management happens at registration time. Obviously, the exact semantics of this will vary by plugin type.

Steps:

  Replace plugin_map with Plugin_registry

  Move plugin_array into Plugin_registry

  Add Plugin class dlsym it

  Using old structs - instantiate a Plugin and put it into Plugin_registry

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.