It would be nice if we could isolate what needs to happen to connect the plugin to the browser from people who don't need to understand the details (like end users, and product bundlers).

Given that each browser has a particular way in which it expects to be informed about its plugin and that we know what those are, we should do more then just document the manual steps involed.

We could provide a script that takes some arguments and does the "right" thing based on that input. The script could live in a well know location, allowing browser installer to find it and connect to the plugin during their install process.

Here is a brief interface design for such a script:

The best place for this script (or actually the logic of the script) would be the ControlPanel script that already is part of the build/distribution.

It would be enhanced to take 5 arguments:

-r (means treat this as an invocation to do registration; don't bring up UI)
-u (means unregister)
-j path (mean path is the location of the Java install)
-c path (means path is the location of the browser/container install)
-s scheme (means scheme is some predefined constant that indicates how the browser/container expects to be connected to)

To start with we could support the following schemes:

ns4 : treat it like a netscape 4 browser (put the link in the plugins directory)
ns4e : tread it like a netscape 4 browser, but just return the appropriate setting of the NPX_PLUGIN_PATH env variable

ns610 : treat it like a Netscape 610 interface supporting browser and use regxpcom.

ns610l : treat it like a Netscape 610 interface supporting browser and put the link in the plugins directory.

[FYI the -j option is needed because how the browser found the JRE is important to things like diskless clients]