July 2008, after TP2 and before V3-Lite

Problems

• The remote command Handling in CLI is completely separate from the Local Command Handling. I.e. almost none of the services provided by the V2 CLI infrastructure are used for remote commands. Many services were re-implemented, imperfectly, from scratch – e.g. command line parsing, handling of generic options like terse and verbose.

• The current paradigm/architecture is that CLI is strictly forbidden from knowing anything_about remote commands. CLI can not assume _anything about parameters. Examples:
  • If CLI sees an argument to a command named "enabled" it is not allowed to assume that this is supposed to contain a boolean value.
  • Say you type in "asadmin -user foo someCommand". CLI is not allowed to assume that remote command names are forbidden from starting with a hyphen (it is allowed in fact). CLI will dutifully call the server and ask it to run a command named "-user" with 2 operands.

Proposed Solution

%%

The basic idea that we can not be aware of what remote commands are available on a server is true at build time but not true at runtime. We can get a thorough description of every remote command – including all the parameters, operands, man pages, help, legal values, etc – at any time by simply asking the server. So the first major change is for CLI to become aware of every remote command.

Note: Try "asadmin list-descriptors". This is a (toy) command that demonstrates that it is fairly easy to get at the needed information about remote commands.

The way CLI deals with local commands is to fully describe the command in XML. At runtime there is a lot of heavily-debugged and massively-tested free code in CLI that uses the data in the XML file to handle and prepare final commands. We need to leverage this for remote commands.

Details

The solution is for CLI to call the server and ask for descriptions of all remote commands that are currently available on the Server in the form of an XML file that CLI can use directly.

Now whenever a command is given to CLI it consults both the static local command descriptors XML file and the current remote commands XML file. Everything is treated at the top several levels exactly the same just like in V2. Eventually we will know it is a remote command (probably from a boolean "remote-command" property that is set for every command) and do the remote command processing. remote command processing will be drastically simpler because the core CLI will have already validated and created a perfect command line to send to the server.

Performance

This is a classic example where it is very tempting to get prematurely involved in performance enhancements.
I'm talking specifically about getting the remote command info, converting into XML and then having CLI parse it.

• How do we cache this information? Serialized file with a timestamp?
• How often do we refresh the information? Is this user-settable? Do we offer a new command to force the refresh?
• etc., etc., etc.

The first order of business is to get it all working properly. The worst-case for performance is getting the remote command info from scratch every time CLI runs. This is also the best-case for getting the most accurate, up-to-date information about remote commands. This may well be "good enough". If the time to do all of that is on the order of (or a fraction of) the network latency time then performance is not an issue. Try 'asadmin list-descriptors' – it is VERY fast.
One easy fast reliable performance enhancement is to wait to get remote command info until an unknown command is entered. E.g. it is a big waste of time (and impossible!) to call the server for a "start-domain" command.

The possibilities for performance improvements are many and are straight-forward to implement. It is not important until much later in the process....