Plugin System



Sorry. Forgot the attachment. :(

I had a long talk with Jody earlier today, and I came up with the
beginnings of a description for a flexible plugin system that would work
for Gnumeric and other applications. Could people look it over and give
comments please?

---  Bob Smith <bob thestuff net>  ---
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++
..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
Different parts of the plugin system.

Main parts:
1. Discovery.
2. Activation.

Notes:
1. Proxies. A lot of programs wont need proxy objects. Let the application provide them.

One main GObject that deals with these features:
1. State property.
2. Add directory. State becomes PROCESSING. Idle callback to update metadata.
3. Remove directory. State becomes PROCESSING. Remove metadata. Idle callback to unload relevent plugins.
4. A function to get a list of directories.
5. Metadata ready signal. Signaled when metadata's fully updated.
6. Metadata property. Tree of stuff created by the Discovery subsystem.
7. Add Discovery object. State becomes PROCESSING. The Discovery object is handed the current directory list and an idle callback is set for it to update itself.
8. Remove Discovery object. State becomes PROCESSING. Remove metadata. Idle callback to unload relevant plugins.
9. Add Activation object. All Discovery objects are informed of the new Activation object. They then update their metadata.
10. Remove Activation object. All Discovery objects are informed of removal. They then update the metadata.
11. Have a property for removing plugins after their final unref rather then leaving the plugin loaded.
12. Have a property for loading service metadata only for enabled plugins.
13. Add service metadata type. Defines a structure for storing the metadata related to a service. Discovery objects are notified.
14. Remove service metadata type. Removes relevent metadata from the metadata tree.

Notes:
1. When a plugin is removed, remove it via an idle handler.
2. Keep in mind the possibility of caching a completed metadata tree (or parts of it) so the next run is faster.
3. Do as much as possible through idle callbacks. The plugin system should stay out of everyone's way.
4. The Discovery and Activation objects should provide enough features to support easy writing of proxy objects.

Some features of a Discovery object:
1. Add a parser for a service metadata type.
2. Remove a parser for a service metadata type.

Notes about service objects:
1. A service almost never can be shared between apps, so information about them (Like metadata description, parsers, and display widgets) should usually be implemented in the application itself rather then a generic library.

Notes about GUI:
1. There needs to be a method for adding GUI elements to support viewing of a service metadata object.
2. All the widgets should be embeddable widgets. So they can be added to the applications normal preference dialog.

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]