Registration Engineering Specification

RFE:   4645618

Author:  Steven Katz
Date: 04 March 2002


1 Project Description

1.1 Overview

The steps needed to successfully register the plugin, with the container, have become to complex for direct user execution.  While the particular steps for any one container may not be so overwhelming, the growing number of containers and their individual idiosyncrasies make it imperative that we assist the user in some way.  A user in this case might be and end user, a developer creating an installation script, or anyone else concerned with plugin registration.

As such, we need to insure that, if the user knows certain information about their environment, they should not have to know the details of plugin/container registration.

The information a user could be expected to know:

The location of the container installation they wish to register with.
The location of the JRE they wish to register with.
The scheme of registration their container employs, from the plugin point of view.

Additionally, once a solution is arrived at and made available, it should be expected to be available for the foreseeable development life of the plugin.  In other words, once it is out there, users should be able to depend on it still being there and being consistent for as long as we produce versions of the plugin.

1.2 Project Dependencies

1.3 OS and Browser Compatibility and Interpretability

Netscape 4.X Netscape 6.X on all supported UNIX platforms

1.4 Performance and Scalability

Performance should not be a gating factor, since we should expect this to be a one time execution for any given container/plugin combination.  Scalability needs to be considered since it is clear that additional containers will need to be supported latter down the line.

1.5 Security

No Factor

1.6 Internationalization (I18N) / Localization (L10N)

No Factor

1.7 Packaging

The way the solution is to be delivered should be simple.

1.8 Usability

1.9 Quality

1.9.1 Unit or Functional Tests to be Delivered

1.9.2 Additional Testing Notes



2 Technical Description

2.1 Architecture

Key to this architecture is the assumption that the user has some basic knowledge (see overview).  It is well within reason to believe that the user knows or could figure out where to find the installation location of both the container and Java.  It is not reasonable to assume however, that the user will know anything about how their container expects the plugin to register with it.  As such, we solve this problem today by providing manual steps for the user to follow for their container type.  This architecture replaces the need for the user to follow the manual steps, with an automated system based on the method of container registration.  In short, a script that does what the user would have done manually, assuming they can tell us which set of steps (by a name we provide) they would have chosen.  This "named" set of steps MUST be document.  Perhaps in some kind of table, such as:

Browser    Steps name

N4.X        Name1, Name2
etc...


Each set of steps should be distinguished in the documentation as to which is preferred, for a given container,  should more then one be available.

A good candidate for this script is the "ControlPanel".  It already exists within the plugin distribution.  It lives in a well know place, and what we are talking about here is something that fits into the idea of a ControlPanel naturally.

So, we will modify the ControlPanel script to take a set of arguments (see Exported Interfaces) and register the plugin accordingly.  Further, should arguments be provided the ControlPanel should assume it is being used for registration and NOT bring up its UI.

2.2 Exported Interfaces/API

ControlPanel [ ( -r scheme | -u scheme ) -c path -j path ]

This means that, arguments to the ControlPanel are optional, but must be specified completely if they are to be used at all.  Each argument means:

-r  scheme | -u scheme: register or unregister the plugin, respectively using the supplied scheme.  only one switch should be specified and only the last one specified will be honored. (for "scheme" values and their meaning see below)

-c path: specify where the ControlPanel script can find the installation location of the container (as indicated by "path")

-j path: specify where the ControlPanel script can find the installation location of Java (as indicated by "path")

Clearly, it should be possible for the ControlPanel to figure out the information supplied by the "-j" argument by default since by definition the ControlPanel lives inside the distribution.  This is not appropriate however, since the information we are really asking for is: "How does the given container locate the Java installation?"  That is, the path a given container might use in not necessarily the same path we would deduce from our location.

Initially, the following scheme (scheme names) should be supported:

ns4: the container uses the Netscape 4.X method of setting the NPX_PLUGIN_PATH variable, the script should return the value that the variable should be set to.
ns4l: the container uses the Netscape 4.X method that assumes a plugin directory, a link is made from the directory to the plugin.

ns600: the container uses the Netscape 6.X method that assumes a plugin directory, a link is made from the directory to the plugin

ns610: the container uses the Netscape 6.X method that assumes the existence of "regxpcom" which is executed on the plugin
ns610l: the container uses the Netscape 6.X method that assumes the existence of a plugins directory, a link is made from the directory to the plugin.

2.3 Imported Interfaces/API

2.4 User Interface

As an example suppose the installation script for Sun verision of Netscape 6.2.1 wished to register the plugin.  We assume that both the JRE and Netscape have been installed by pkgadd in their default locations, but the actuall installation script would be free to chose some other values for the installation locations based on its needs.

The command the script would run would look like:

/usr/java/bin/ControlPanel -r ns610 -c /opt/SUNWns6 -j /usr/java


3 Marketing

3.1 Justification

3.2 Customer Request

3.3 Competitive Analysis



4 Management and Planning

4.1 Scope/Priority

4.2 Target Release

4.3 Resources

4.3.1 Development

4.3.2 Quality Assurance/Testing

4.3.3 Documentation

4.3.4 Technical Support

4.3.4 Special Hardware/Software

4.4 Schedule

Start Date End Date Activity Owner Status
 04.03.2002    Initial draft  smk  started
         
Complete Started Not Started Difficulties Trouble


Appendices (as needed, suggestions below)

A. Background Information

Numerous problems lead to the need for this proposal.  Chief among them where the inability to properly communicate the steps to register the plugin to the world as a whole and to groups inside Sun in particular.  Additionally, several customers have complained that the registration process should be easier.  Once this system is in place the hope is that groups that supply products that wish to use the plugin will find this method more reliable and predictable and as such make more of an effort to connect to the plugin during their installation process.

B. Interface Specifications

C. Notes and Additional Details

D. Miscellaneous

E. Tracking

E.1 Final Webrev

E.2 Bugtraq
Bugid P S Subcategory Type Engineer Synopsis
 4645618            



Revision History

Date Version Author Description
 04.03.2002 0.1  smk  Initial draft