<SNIP> > There are 3 layers of restriction that I can think of > > 1) The plugin loader can not unload things (eg your example of > systems that do not support unloading) > > 2) The plugin itself is using resources that it can not shut down > easily. > > 3) A service in the plugin is inuse or unable to shut down. > > It seems relatively easy to handle all three. > Agreed. The one question I have is, how much of this can be determined ahead of time so, say, the GUI for loading/unloading can gray out loaded unloadable plugins. As for number 2, I always thought that the plugin object was uninheritable. Are we going to be able to subclass the plugin class? > > > This is interesting. As I understand it, you would have to use a proxy > > object correct? Are you talking about reloading a plugin where the > > application doesn't know the plugin was ever removed? > > There are two choices, proxies, or a registry of service users. > This would be handled at the application level. How I was thinking of it is if: 1. All services of a plugin that are used in an app were gotten as proxy's from the plugin manager 2. All services of the plugin notify the the plugin manager that they do not function as a generator, say, returning an object defined in the plugin. Then you can have the plugin manager keep track of pointers to all proxy services returned, and update their internal service pointer when the plugin is reloaded. (Or, null out the pointer so that the proxy will retry to get the service next access) But, there is one problem left to be resolved. What happens when a plugin is reloaded, and the old plugin worked, but the new plugin fails to load? Well, come to think of it, a proxy service will have this same problem if the plugin fails to load. How should we handle proxy services that fail to load plugins? -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part