Here's what I'm picturing -- it's a conglomeration of the ideas presented.
1. srfsh defines an internal register_command function where all commands are registered. It takes a command name and a pointer to the handler function and stores them in a hash. 2. the config file defines something like <extension object="eg_extensions.so" init="oils_init"/> - where init is some function the plugin implements, which returns maybe a hash of command -> implementing-function-pointer pairs. 3. srfsh iterates over the plugins, calls the init function, then iterates over the returned items and calls the internal register function on each command to add them to the global command registry. (I'm not sure about duplicates. I'm fine with "give your command a prefix of some sort (e.g. oils_login) and if it clashes with another command, the last one loaded wins (with a warning)"). My thinking with the init function is so the plugin can perform other tasks during initialization. For the ILS, parsing the IDL is an obvious setup task. An additional benefit of supplying a srfsh-internal register function is so we can setup tab-completion of commands at registration time (at some point in the future). This is obviously on the side of "more work" ;) -bill
