[news.eclipse.technology.equinox] Re: How are dependent plugins handled

["Kevin" <kduffey@xxxxxxxxxxxxx>]

Mel,

You hit it right on the nose with your reply. What you wrote is exactly what
I was thinking. Either every plugin that depends on another must listen for
a notification that the plugin it depends on may be deactivated, unloaded,
reloaded, etc, OR, you have to code for it with a bunch of checks, making
sure a reference to a plugin is not null before doing anything with it. On
the thought of making SomePlugin a local variable, I agree and disagree. I
can see arguments for and against this, in that, if many methods of a plugin
call upon a dependent plugin, and let's even go as far as saying one method
may be called a LOT quickly, then every call to any method using the plugin
takes up time by making several method calls just to get the ref to the
plugin they wish to work with. There is the one call to get the ref, and
internally you know the engine is doing lookup to find the plugin, probably
via internal method calls, and so forth. So my biggest concern with the
approach of always using the dependent plugin ref as a local variable is
speed. On the flip side, you NEVER have to worry about
unload/reload/deactivated issues. You simply get the ref, and if its null,
don't use it.

I don't know a lot about OSGi, or much about Eclipse (although more than
OSGi), but a few things I read here suggest that OSGi works in the way of
services, where by a plugin requests a dependent plugin and has to code for
the possibility that the dependent plugin service is not available. To me,
in order to support unload/reload/deactivate capabilities, EVERY plugin
should be coded in this manner, always prepared for the worse case. I also
think there should be the option to "lock" a plugin from ever unloading or
being deactivated. There may be times where "core" plugins must be available
at all times and could have many, if not all other plugins depend on them.
To unload or deactivate a core plugin would basically be like restarting the
application, only a bit faster because you are not shutting down the JVM and
restarting it, you are simply unloading all plugins, then reloading them. I
do believe this is ok though, so long as plugin developers are aware of what
may happen. I also think any application that uses a plugin engine to allow
reloadable core plugins is not designing very well. Whatever name is given
to them, the idea is that core plugins are crucial to the application, and
should most likely not be unloaded/reloaded at runtime. That said, I also
think the engine, for flexibilitie's sake, should still allow ANY plugin to
be reloaded, and either the notification sent to all dependent plugins, OR
the engine automatically just deactivates those plugins, reloads the plugin
they depend on, then activates them again. I think this is indeed possible.
If plugin A depends on B, and b gets reloaded, the engine should deactivate
A. So what happens if plugin C depends on A? Well, when A receives notice
that it is deactivating, C should also receive notice, and so on up the
chain of ALL dependent plugins. Upon reactivation, each plugin would have to
get its dependent plugin refs again possibly.


Lastly, I like your idea of a single application that allows "pluggable"
applications for the sake of integration. I am working on a pluggable
internet suite of apps, where by the email plugin, ftp plugin, irc plugin,
newsgroup plugin and so forth can all share a common platform to run under,
copy/paste is more seamlessly integrated, they can share the same
"addresses" so to speak, the same internet connection and so forth. My goal
is to create a complete Java internet suite of apps that would work on
Windows, Mac, Linux, Unix, etc. I know, there are plenty of
shareware/freeware/open-source projects out there. Well, one of my main
reasons for creating my own plugin engine from over a year ago is I like the
ability to architect and change things to the way I like them. The concept
of open-source is great, but to me plugins are the golden ingredients. Being
able to plug in my own email application that I wrote and use it and fix/add
to it as I see fit is better to me than hoping some change I added gets
accepted and committed to a project. Not that this is bad, open-source is
great. I just think I like the notion of adding in my own ideas rather than
hoping they'll get committed.

So here is a bit of thought, for anyone reading this. Maybe I just don't
know enough about OS's, but to me, it seems a tiny little "core" OS that is
nothing more than a plugin engine would provide the golden OS. That is, make
a tiny plugin engine core, that can then load plugins dynamically,
unload/reload them at will, like what we are discussing. Only, instead of
loading all fonts, print drivers, video card drivers, it only loads those
needed. I for the life of me can't see why Win2K requires SOOO much memory
to load, or OSX for that matter. And, I for the life of me can't figure out
why it is so difficult to configure these things. Sure, I agree that core
level stuff like the HAL, device drivers for things like ports, keyboards,
etc should be loaded to some extent. But do I really need to support 200
different kinds of mice and 80 keyboards? No, I have only one of each. Do I
really care to support the VGA mode I'll never use again because my video
card supports DVI? No! So why load it? To me, this stuff should be loaded
ONLY if its needed, not "just in case". If I had the nohow, I would love to
write an OS like this, because to me, this is the OS that could run on any
platform and easily be ported for most hardware, including set top boxes,
PDA's, etc. Well, just a thought provocation! I am sure there is a LOT I
don't know about how these things work. I would just love to start doing
something like this one day, but I am sure the most common question (and
reason for lack of acceptance) would be "Why another OS? We have plenty". My
thought is, build it around the Linux core, but find a way to avoid the long
boot up times and all those modules loading. I also love the idea of the OS
having a GUI layer plugin added, rather than always there. I think MS is
really missing the boat (and OSX as well) by not allowing a "scaled back"
version of their OS that has remote GUI admin capabilities that don't
require the entire GUI subsystem to be loaded. If the only thing I need
Win2K for is to run a web server, why do I need the tons of memory eating up
by the GUI layer? Just give me the HAL and a few things I need to run my
J2EE server damn it!

Ok, enough of rambling.



"Mel Martinez" <melm@xxxxxxxxxx> wrote in message
news:b69psn$kb0$1@xxxxxxxxxxxxxxxx
> Kevin wrote:
> > Hi am curious, if a plugin is unloaded or reloaded at runtime, how are
all
> > dependent plugins treated? Do they all get unloaded by the engine, then
> > reloaded and reconnected when the requested reload operation is
completed?
> > Or do they just sit idle, hoping that events or what have you do not
come to
> > them that require their code to work with a plugin that may be in the
middle
> > of a reload (or might have been unloaded completely)?
> >
>
> It kind of depends on the nature of the dependency.  If the dependency
> is based on class visibility, like so:
>
>    SomePlugin p = (SomePlugin)Platform.getPlugin("some.plugin.id");
>    p.someMethod();
>
> Then if the SomePlugin class gets unloaded and reloaded, the above code
> will no longer be valid and would also have to be reloaded.  If the
> dependency is indirect and only through platform API's:
>
>    Plugin p = Platform.getPlugin("some.plugin.id");
>    p.setDebugging(true);
>
> Then this code MAY be decoupled, so long a it doesn't try to statefully
> retain the reference 'p'.   I.E., 'p' should be a local (method)
> variable and never stored in a class or instance variable.  A way of
> working around that limitation is to use the Observer pattern to notify
> dependents via events that SomePlugin is about to be unloaded.  An event
> listener callback method could then be used to release (nullify) any
> instance or class references to the plugin (or any class provided by the
> plugin).  Another alternative is to write your code ready and willing to
> deal with ClassDefNotFound and NullPointerExceptions.  :-)  Not a bad
> idea in general, really.
>
> > My initial assumption is that somehow the engine must "pause" or
completely
> > unload all dependent plugins as well. My concern here if it is done in
this
> > manner is the time to reload a single plugin could be noticeable.
However, I
> > guess the question to be asked is, how often is any plugin reloaded at
> > runtime anyway? I can't think of any application, other than perhaps an
> > application during development/debug cycles, that would require plugins
to
> > be reloaded at runtime, with the exception of an application that may
check
> > for updates via a menu item click or button click, and if found, would
> > auto-reload the new version of the plugin. In most apps, like Photoshop,
3D
> > applications, even Eclipse, the most common place to reload a plugin is
> > actually at the start of the app, where it may load the plugin the first
> > time if a new version exists. I really don't see a strong need for
reloading
> > during an application execution.
> >
>
> My group has a very very strong interest in the ability to add/remove
> functionality during runtime with varying degrees of integration.  I'm
> not sure I want to or should get into the specifics of our particular
> use cases.  However, consider the analogy to broadly-purposed
> application platforms such as a web-browser, which can run a variety of
> independent thin-client applications (html pages, javascript, applets,
> flash) that are loaded/unloaded/reloaded independent of each other, yet
> still gain additional utility through consistency of the platform and at
> least a thin layer of integration.  Perhaps a better example might be
> Lotus' Notes, which provides a vehicle for the deployment of a great
> variety of much richer, full-featured (thick) applications that can be
> added/removed from the user's environment yet still have a high level of
> consistency and integration.
>
> Mel
>