[jos-general] command mechanism

[Gilbert C. H. II <gc...@mi...>]

Your help is needed. Please review the following proposal. Your comments
and suggestions are welcome.

I am working on a Java-based operating system in order to (1) learn more
about Java technology, its strengths and limitations, (2) to extend my
professional development environment, and (3) re-use class libraries in
production applications. I continue to believe that a Java-based operating
system is a worthwhile goal. I continue to look for a robust "command"
mechanism worthy of a world-class operating system.

The proposed command mechanism is simple and open-ended. Anyone can
distribute a jar compatible with this mechanism. Anyone can build a command
container. Help is needed to write the command API specification. Help is
also needed to test and contribute to a robust class loader.

A "command" mechnism could be similar to the "service" mechanism, which
depends upon resources. Or, it could require entries in
META-INF/MANIFEST.MF like OSGi.

Let me illustrate my basic proposal with the cd command and a classic
command-line prompt.

1. Type cd and press enter.
2. A command name is transformed into the name of a resource. "cd" becomes
"META-INF/command/cd".
3. The resource is found with the help of a class loader.
3. The first line of the resource is treated as a class name.
4. The command class is found with the help of a class loader.

Let me illustrate how to invoke an arbitrary command class.

1. Type a command class name, such as org.jos.demo.Demo, and press enter.
2. There is no matching resource.
3. The command class is found with the help of a class loader.

What is a command? There are many possibilities that are supported.

1. A classic Java application, where the command class implements a public
static void main(String[] args) method.
2. An AWT-based component, where the command class extends
java.awt.Component. Your command-line might provide an AWT container.
3. An applet, where the command class extends java.applet.Applet. Your
command-line might provide an applet container.
3. A runnable class, where the command class implements java.lang.Runnable.
4. A subprogram, where the command class implements org.jos.program2a.Program.
5. A servlet, where the command class implements javax.servlet.Servlet.
Your command-line might provide a servlet container.
6. Implements an interface, an abstract class, a class that is yet to be
determined.

The "current" classloader is used to find external resources and command
classes. If available, the META-INF/command/classloader resource contains
the name of the command class.

1. Type classloader and press enter.
2. The status of the current classloader is displayed.

To create a new class loader, use the proposed setclassloader command. If
available, the META-INF/command/setclassloader resource contains the name
of the command class.

1. setclassloader [directory-1 [directory-2 [..]]
2. The current classloader is replaced with a new classloader.

Built-in commands are part of the command-line container and cannot be
modified at runtime. The build-in classloader points to a list of
directories. Each directory contains one or more jars.

A. A jar can provide a resource for commands.
B. A jar can provide command classes.

Note: The Universal Browser provides an AWT-based command-line container. A
command-line is passed to Smart API 4a. The Smart API 4a can be extended to
support a command mechanism. If available, the META-INF/command/ub resource
contains the name of the command class for the Universal Browser.

The proposed command API hides all of the details. The latest version is
found in the org.jos.command package. It is used within your Java
application or command container, something like this:

 public void example() {
   CommandFactory f = CommandFactory.getInstance();
   Command c = f.getCommand("cd");
   c.run();
 }

If available, the META-INF/services/org.jos.command.CommandFactory resource
contains the name of a service class for the CommandFactory service.

Thanks,